MichalFranc

This is the written version of my talk at Programistok 2026 in Białystok. You can click through the slides here. The talk itself was light on tools and heavy on careers - where our profession is heading and how to get ready for it.

A small joke to start. On the title slide I crossed out "AI" and wrote "SI" - Super-Intelligence, as apparently we are supposed to call it now (Reuters, 22 Sep 2026). The fun part is that it works twice for a Polish audience: in Polish "SI" has always meant Sztuczna Inteligencja - artificial intelligence. Same two letters, same joke, two languages. It also sets the tone I wanted for the whole talk: less hype, more distance.

2026 - intense, chaotic, uncertain

2026 feels intense and chaotic. There are many possible scenarios and two very loud extremes:

• The deniers - "it's a bubble, it will pop, everything goes back to how it was. We don't need to do anything."
• The maximalists - "there is no point doing anything, AI will take our jobs anyway."

What I find interesting is that both extremes end in exactly the same place: passivity. Do nothing and wait. The truth, as usual, is somewhere in the middle - and the middle is the only place where you can actually act.

So what do I think is coming by 203X? The market will change. The roles will change. In 5-10 years we will look back at 2026 very differently than we see it today. Right now it's nervous because we are at the beginning of a journey. The future will be good - but it won't be free. It will take effort, and that effort means actively working alongside AI and the new tools, not waiting to see what happens.

Why listen to me?

~20 years in the industry, the full path from junior to senior staff engineer, mostly at UK and US product companies - JustEat, JustGiving, Form3 and now Affirm. These days I work as an architect of distributed systems and of organisations - scaling both systems and people, across teams, for products with tens of millions of users and billions of dollars flowing through them. That last part - working on the system and the organisation - is pretty much the thesis of this post.

The evolution that got us here

To talk about the future, let's first look at the direction we've been moving in. Software keeps getting more complex. We went from simple programs (scripts, Excel) to desktop, then web, then mobile, then globally distributed systems. We still build simple things - but the ceiling keeps going up, and what used to be exceptional becomes the norm.

Complexity forces technology changes

When complexity grows, technology wraps it in something simpler so we can handle more. Assembly and manual memory management gave way to high-level languages, then frameworks, then the cloud, then orchestration like Kubernetes. Each layer hides the complexity of the one below.

But a layer doesn't only hide complexity - it makes hard things cheap and accessible. Running your own data centre, managing memory by hand, scaling to millions of users: once elite work, now out-of-the-box for pennies. Technology democratises complexity, so more people can build more complicated things.

I remember reading highscalability.com - articles about sharding, database partitioning, clever SQL - and it felt completely out of reach for me as an engineer at most companies. With the cloud and orchestration, all of that became widely available. AI is simply the next step on those stairs, following exactly the same logic.

Skills demand keeps shifting

The same evolution, seen through the skills the market asks for. Every era - desktop, web, cloud & mobile, AI - brings different skills to the top. Manual QA and the classic DBA/sysadmin got absorbed by automation and the cloud; you can literally see the DBA line drop as cloud rises around 2012-2015. OOP grew from 1995, peaked around 2010 and then declined - it didn't disappear, it became the baseline. When I started, OOP was the skill. Today it's just standard.

The takeaway: don't tie your identity or your ego to one technology. Not "I'm a .NET developer". The demand curve moves, and your identity shouldn't be sitting on top of one line of it.

Less how - more what and why

Look at what being an engineer consisted of over time. Algorithms and writing code used to dominate. That band keeps shrinking, while system design and domain expertise grow. Code doesn't disappear - it just stops being the majority of the job. The centre of gravity moves from "how to write it" to "what are we building and why".

Complexity shifts the roles too

It's not only technology that moves - roles merge as well. Frontend + backend + QA became the full-stack engineer. Backend + IT ops became DevOps. DevOps + security became DevSecOps. Full-stack + business became the product engineer - and here the new dimension is business, not another technical discipline. And full-stack + DevOps? We don't even have a name for it yet. Not every merge has a name, which tells me we are in the middle of the transformation, not at the end.

Specialisation doesn't stand on its own anymore. It sits on top of a broad shared base - a bit of everything with depth on top, the classic T-shape.

From skill silos to domain silos

The same force reshaped organisations. With simple systems, a separate QA team, a separate dev team and a separate ops team worked fine. With complex systems, the handoffs "over the wall" and the queues between silos became the bottleneck. So we regrouped teams around a domain - Payments, Checkout, Search - with QA, dev and ops inside, owning the value end-to-end. Team Topologies, stream-aligned teams, DDD bounded contexts - all answers to the same complexity problem.

And the pattern keeps repeating. Specialists said "this can't be automated", then the cloud and automation arrived. The role didn't vanish - it shrank and moved into the team. Next in the queue: writing and reading code by hand.

Evolution, not revolution

Complexity + cost + more users → the industry builds a tool to manage it. That loop has been running for decades. AI is not an accident and it's not a revolution. It is the natural consequence of the same forces - market pressure and growing complexity - that have been at work for 20+ years. The only difference is speed: it moved slowly for decades, and now it's speeding up.

What comes next? Predictions, not promises

The direction is clear - so the question is no longer whether, but how this evolution will unfold. An honest disclaimer first: I don't claim any of this will happen for sure. Someone might say "in 10 years it will look nothing like this" - and they might be right. These are my bets, food for thought and for arguments over coffee. Vision and provocation, not a hard forecast.

The local-optimum trap

Software 1.0 + AI - agents doing today's work, just faster - gives a quick, tempting boost. But it's only a small hill. It looks productive and it's short-sighted.

This one is personal. 20 years of experience means very deeply trained "neural networks" in my head - I think about software in 1.0 mode. When I apply AI to that thinking, sure, I get more code and some extra value... and I walk straight into the local optimum. My brain is a model trained on old data.

The real peak is higher: Software 2.0, where you aim at value and outcomes, not faster tasks. To get there you have to come down from the small hill, cross the valley (rethink how we build), and climb the right peak. The good news is that most of the industry is still climbing the small hill. The trap is still ahead of us, which gives us a window to aim for 2.0 directly.

Escaping it: question every 1.0 habit

This isn't about tools. It's about challenging our own habits and the way we learned to think. Four quick examples - each with the same question: to go faster, do we have to...?

Code - do we stop hand-writing every line?
In 1.0 we write most code by hand. In 2.0 we barely do, and hand-written code becomes a niche - like writing a native C++ extension for a Java library today: a small number of people do it, for critical cases. A year ago, saying "AI will write the code for us" made you sound detached from reality. Today most of the engineers I know have accepted it.

Review - do we review system health instead of code?
This is the big one. Agents write the code, we don't fully trust them, so the temptation is to review every line even more carefully. Companies that do this discover that review becomes the next bottleneck and kills velocity.

In 2.0 review moves up the stack: we look at the behaviour of the whole system, not the diff. We define measures - does this change (on staging or production) have a positive effect for users, or does it cause a regression or a business problem? A/B tests, experiments, canaries, watching real user behaviour. To be clear: 2.0 doesn't mean "we stop verifying". We move verification higher. Ownership stays with us.

Determinism - do we accept non-determinism?
Software 1.0 is driven by logic: the same input always gives the same output, and our job is to decide what that output should be. 2.0 is a different world. We don't reason a model into an answer - we create an incentive for it to give us one. Input 5 gives 42 almost every time... and occasionally 43.

So: 100.00% vs 99.99%. Are we OK with that 0.01%? I think yes - if the layer around it handles it. Architecture, system design and UX catch the deviation and deliver a stable product. We stabilise the whole system, not every single answer.

We have done this before. Distributed systems and NoSQL consciously gave up guarantees - dropped ACID, moved to eventual consistency - to scale and go faster, and then we engineered around it. Same trade, now at the model layer.

And honestly, determinism was always a bit of a lie. Unsynchronised threads: A does x += 1, B does x *= 2, and depending on the scheduler you get 2 or 1 - same code, same CPU, two results. JIT compilers produce different machine code for the same bytecode depending on runtime conditions. CPUs execute micro-ops out of order and speculatively. The same source can produce different binaries, which is why "reproducible builds" is its own movement. Determinism was always engineered on top of chaos - we just handled it a layer down, with memory models and locks. AI doesn't bring non-determinism into a perfect world. It moves it up, into application logic, where we now need the same discipline.

Practices - which do we keep, rethink, add?

• Keep: 12-Factor, CI/CD, observability, SRE, continuous delivery. These don't care much whether a human or an agent wrote the code. SRE in particular - SLOs, error budgets, blast radius, graceful degradation - is literally a language for imperfect systems, which is exactly where the 0.01% lives.
• Rethink: Clean Code, KISS, YAGNI, SOLID, OOP. Many of these were written for a human reading code. Some will stay, some will be redesigned. Cleaner code still helps models (they were trained on it), but the "why" behind the rules is shifting.
• New: context engineering, harness engineering, spec-driven development - plus a few question marks, because this discipline is only just emerging.

So it's not "the principles are gone". It's keep + rethink + new, all at once. The craft still matters - it's just changing shape.

What does it mean for you?

The role itself is changing - not just the tools or the way you use AI. You need to shift how you approach the job towards impact and value, and become part of the decision process - what we build and why - not just the execution.

The centre of attention moves

AI is strongest at the "how". So human value moves to where AI is weakest: the what and why, the domain, the value. This isn't "AI takes our jobs" - it's the unevenness of augmentation that moves where your value lives.

From ticket machine to owner

Old world: someone else decides what and why, someone else owns the outcome. You sit in the middle of the line - ticket in, code out - and the value is assembled somewhere else. New world: you're in the middle of the loop - problem → decision → build → outcome → again. The build is increasingly done by AI. Your job is the decisions and the outcome.

That's the difference between doing tasks and having agency. A task means someone else owns the problem. Agency means you take the problem on and deliver the value.

Soft skills are your multiplier

Let me be clear, because "soft skills" is a cliché. I don't mean "a leader who's good at talking to people". I mean driving something from A to Z - roadmap, product, development - taking responsibility, and feeling like an owner of your slice of the company. You need the whole triad:

• Responsibility for the outcome - you're on the hook for the result.
• Ownership of the problem - you take it end-to-end.
• Agency - you push the change, you don't wait for someone to tell you what to do.

Above it sits judgment: knowing what a good solution is and how to apply the triad. Still engineering work, just higher up - less typing, more deciding. Technology multiplied by this triad gives a lot more value. Technology without it multiplies by roughly one.

Seniority, redefined

Seniority used to mean "knows the framework". Now it means "can take a problem and deliver it on a given scope". Same problem, different altitude:

• Junior - add an index to the database
• Mid - fix the API's p99 latency
• Senior - page load time
• Staff - bounce rate
• Principal - business metrics are dropping

Scope and impact grow together, from tactical to strategic. Hard skills dominate at the start but flatten out around senior. Above that, soft skills make the difference, and at staff/principal it's domain knowledge. Hard skills get you in - they don't take you up. This should change how we grow people and how we hire: promote and hire for delivery, not tenure.

Join, contain, steer

Three verbs for what the engineer does around AI.

Join. AI produces pieces - code, tests, APIs, UI, data, infra. On their own they don't hold together. You are the glue that bonds them (contracts, tests, integration, judgment) and the water that fills the gaps. Only bonded do they become a molecule with new properties: a working product. Verification moves from reading every line to tests and contracts - checking the whole works, not each brick. I saw this first-hand building mods for Quasimorph: AI made the pieces, I made them into something that actually works. My bet is that by ~2036 this is the default way engineers work.

Contain. AI adds entropy. I've had projects where I let AI do everything - didn't read the code, didn't write any - and over time they drift apart and each change gets harder. Nothing new: neglected projects looked exactly the same 20 years ago. AI just accelerates the build-up of chaos. Good design, context, experience and course-correction are the counter-force. Cohesion doesn't maintain itself; someone has to hold it.

Steer. The long horizon is ours. Models are trained for a short horizon - they optimise for "the next 5-30 minutes", not "two years from now", and mostly want to please the operator. The longer they run, the more they drift. Maybe that changes; today it's true. So you set the road - the goal, the direction, what "good" means - and keep bringing AI back onto it. That's why system design, architecture and clean code still matter. Bonus: the better the road is laid out, the better AI performs on it.

And one more thing sits under all three: you define "good enough". It can't be perfect - the market kills the slow. But "just make something good enough" thrown at an AI gives you something random. AI doesn't know what risk the business accepts or where it's OK to cut corners. The more answers AI hands you, the more valuable it becomes to judge them and ask the right questions. Comfort with ambiguity is a core skill for the future.

How to prepare

Each step up is a bigger scope you take on. Under each - how you work, and one habit with AI.

Level	Own...	How	With AI
Junior	a problem	Even a small one, but end-to-end - you're the owner from day one. Fundamentals (memory, HTTP, algorithms) over attachment to a stack; they are your entropy control, even when the stack hides them.	Learn it. Treat it as a craft, not magic. Build intuition for where it works and where it fails - that takes hours of practice.
Mid	the outcome	Focus on the "why" before the "how". Problems, not tickets. Push for change; grow domain and business sense (T-shape).	Delegate to it. Hand it the "how", so you have time for the "why".
Senior	system health	You make the trade-offs - what we give up to deliver (like that 0.01%). Mid asks "why"; senior decides what to trade.	Contain it. Join, contain, steer.
Staff+	the direction	Connect technology with business, translate one into the other, set direction across teams. Managing up, relationships, looking past your own bubble.	Build a system around it. The harness - environment, context and guardrails where teams can work with AI safely.

Learn it → delegate to it → contain it → build a system around it. The tools are the same at every level. What grows is the problem you take on - and how you use AI inside it. The window is open now; those who start early will reap the benefits.

Don't give in to the negativism

Every generation is told the industry is ending. When I entered the market, in the depression after 2008, people wrote that it was the end of the engineer's freedom - agile, process and managers everywhere. And the generation that entered during that complaining saw as an eldorado exactly what the previous one called the end. In 2036 someone will write that the eldorado is over, and call 2026 its start.

Another rhyme: when I started, Java was gatekept. "You're not a real engineer if you use Java - real ones use C/C++ and manage memory themselves." The gatekeepers were on the wrong side of history. We hear exactly the same gatekeeping about AI today.

AI burnout and losing the joy of the job are real. But ask where it comes from - the intensity, or the changing nature of the work and new roles? In a few years this will fade as we get used to it. The real danger is negativism and bubbles where the work starts to disgust you. Speaking as a nerd who loved assembler and managing memory by hand, who hated the "boring" post-2008 work of frameworks and high-level everything - I changed my attitude and found new specialisations worth mastering. And as someone turning 40 soon, I'm apparently supposed to be the one complaining the most.

It will stabilise again

It was stable, since ~2024 it's turbulent, and at some point in the 2030s it will stabilise again. The middle isn't only chaos - it's an opportunity. Early movers reap the rewards, as in every wave. What brings order is new tools, new practices, new patterns - and collective intelligence: the industry learning together at conferences, in communities, by sharing what works. Nobody figures this out alone.

We are in the front seat

By the nature of our work, programmers use AI, LLMs and agents more and more deeply than anyone else. We get a glimpse of what's coming for everyone. That front-row seat is a real advantage: we can prepare earlier and better than any other field. Use it - watch, experiment, position yourself for what you can see coming.

Quo vadis IT?

It's all evolution. The market changes. The roles change. The practices change. We've been through this many times - assembler, frameworks, cloud - and we know how to handle it. The direction is readable even if the details aren't.

What stays yours: responsibility · ownership · agency. That's where I'd invest.

Thanks to the Programistok organisers and everyone who came to the talk and the hallway discussions after. If you disagree with any of these predictions - good, that was the point. Let me know in the comments.