I went to Developers Day 2026 Thessaloniki

This Saturday, I attended the Developer’s Day event in Thessaloniki.

The event was organized through kariera.gr and gathered a mix of engineers, speakers, and people trying to map out what the next few years of software development will look like.

First impressions

The atmosphere was typical of modern tech conferences: a blend of excitement, curiosity, and a low level anxiety about how fast the industry is changing.

What stood out immediately was the diversity of talks. Some were very practical deep dives into systems, architecture decisions, and real engineering trade offs. Others were more conceptual and, unsurprisingly for 2026, heavily centered on AI.

The strong talks

Some sessions were genuinely valuable because they stayed grounded in engineering reality:

• Engineering decisions where constraints actually mattered
• Honest breakdowns of performance, scaling, and maintainability

These were the talks where you walk out with something concrete patterns, warnings, or mental models you can actually reuse.

The “AI everywhere” narrative

A noticeable portion of the talks followed a familiar script:

“AI is changing everything. Developers must adapt. Everything is becoming AI-driven.”

That message is not wrong. It is just increasingly repetitive.

At this point, the industry narrative around AI often feels saturated. The framing tends to drift toward inevitability and abstraction rather than engineering detail. And after a while, it becomes exhausting to hear variations of the same claim without much differentiation.

What gets lost in that repetition is something more practical:

• AI still produces code that needs careful review
• You still need to understand architecture and edge cases
• You still need to debug, verify, and maintain systems
• You still need judgment

In other words, the core responsibility of engineering has not disappeared.

A more grounded reality

One of the recurring thoughts throughout the day was simple:

Even with AI tools improving rapidly, writing and understanding code manually still matters.

In many cases, it is still the optimal path because:

• Writing code forces clarity of thought
• You understand constraints better when you build step-by-step
• You are less likely to miss subtle logic issues
• You maintain long-term ownership of what you ship

AI can accelerate scaffolding and reduce boilerplate, but it does not replace the cognitive process of understanding a system.

If anything, it increases the importance of that understanding—because you are now responsible for validating more output, faster.

The skill question

A concern that came up indirectly across several talks was skill atrophy:

If developers rely too heavily on generated code, do their skills degrade?

The answer depends less on the tool and more on usage patterns.

If AI is used as a shortcut without verification, then yes, understanding can weaken over time.

But if it is used as:

• a brainstorming partner
• a refactoring assistant
• a documentation accelerator
• a test generator
• a second opinion

then it can actually reinforce learning rather than replace it.

The key distinction is whether you remain in the loop of reasoning.

The event was worthwhile, even with its thematic repetition. The strongest value came from talks grounded in real engineering problems rather than broad industry narratives.

The AI discussions, while overrepresented, still reflect an important tension in the industry: we are trying to integrate powerful tools without losing the fundamentals that make software reliable in the first place.

If anything, the takeaway was not “AI changes everything,” but something more precise:

AI changes how we work, but not why we need to understand what we build.