AI Can Write the Code. But Who Understands What We're Shipping?

Kiss the Future AI Summit 2026, Sarajevo — reflections from day one on AI agents, the future of software engineering, and conversations from the Engineering Stage.

Today, October 15, 2026, I attended the first day of the Kiss the Future AI Summit in Sarajevo, bringing together professionals from across the technology industry to discuss artificial intelligence and its growing role in real-world systems.

I was particularly interested in the Engineering Stage at the Bosnian Cultural Center, where discussions focused on software development, autonomous AI agents, and the challenges of deploying AI-powered systems in production.

One of the highlights was the panel Builders and Operators — What It Takes to Scale AI in the Enterprise, featuring Nick Miller (Cursor), Pedro Rodrigues (Supabase), Hani Zahirović (Bloomteq), Shayan Aziz (Xplor), and Elvir Dolić (PALFINGER), moderated by Džefris Dizdarević from Lufthansa Technik.

While the panel covered several aspects of AI development, I found the discussion about trust, automation, and engineering responsibility particularly interesting.

Nick Miller: Building Trust in AI Agents

It was particularly interesting to hear from Nick Miller, Founding Field Engineer at Cursor.

Discussing the future of AI-assisted software development, Miller emphasized the importance of gradually increasing the responsibilities assigned to AI agents.

Rather than suggesting that developers should immediately hand over complete control, he focused on creating environments where agents can be trusted to perform increasingly complex tasks within clearly defined boundaries.

“Setting up frameworks where you can trust your agents more.”

— Nick Miller

He also discussed the concept of a software factory, where AI agents progressively automate more parts of the development process.

The interesting part of this approach is not simply generating code faster. It's changing how engineering work is organized and allowing developers to focus more on architecture, decision-making, and solving difficult problems.

Should We Stop Writing Code Ourselves?

Toward the end of the panel, the moderator asked an interesting question: what is one thing engineers should stop doing on Monday?

Shayan Aziz from Xplor gave a rather provocative answer: try not writing code yourself for a week or two and observe what works and what doesn't when relying more heavily on AI tools.

Nick Miller responded that he had considered suggesting something similar.

While that might initially sound radical, it illustrates how quickly the day-to-day work of software developers is changing.

Writing code is becoming only one part of the engineering process. Understanding the problem, designing an effective solution, and knowing how to use the available tools are becoming increasingly important.

Pedro Rodrigues: Stop Shipping Code You Don't Understand

Pedro Rodrigues presenting Your App Needs an MCP Server on the first day of the summit. Photo: Din Arijan Dodik.

Perhaps the most memorable statement of the panel came from Pedro Rodrigues, AI Tooling Engineer at Supabase.

“Stop shipping code that you don't understand.”

— Pedro Rodrigues, Supabase

He went on to explain that generating code has become remarkably fast and inexpensive, but that engineering responsibility hasn't disappeared.

He highlighted the difference between an experimental application and a production system used by real, paying customers.

Another important point was that software engineering was never fundamentally about writing good code. Code is a means to an end, and the actual purpose of engineering is to solve problems.

I strongly agree with that perspective.

AI can now generate substantial portions of applications, but that doesn't mean an engineer's job is finished. Someone still needs to understand the architecture, evaluate security implications, manage integrations, and ensure the system behaves reliably in real-world conditions.

Especially when developing software for clients, having an application that appears to work is not enough.

You need to understand why it works, how it works, and what happens when something goes wrong.

MCP Servers and the Infrastructure Behind AI Applications

Following the panel, I also attended Pedro Rodrigues' session, Your App Needs an MCP Server.

The Model Context Protocol (MCP) provides a standardized approach for connecting AI applications with external tools, services, and data sources.

As AI agents become more capable, the infrastructure that allows them to access information and perform actions becomes increasingly important.

It was particularly interesting to see how tools such as Supabase fit into this evolving ecosystem, where AI is becoming an integral part of application architecture rather than simply an additional feature.

As someone working on web applications and automation, I found these practical engineering discussions especially relevant.

My Takeaway from Day One

My main takeaway from the first day of the summit is that AI isn't just changing how we write software. It's changing what we expect from software engineers.

Automation makes it possible to build faster, experiment more frequently, and develop increasingly complex systems with less manual work.

However, faster code generation doesn't automatically produce better software.

Understanding architecture, security, business requirements, and the responsibility that comes with delivering a working product remains essential.

AI can write the code. Engineers still need to understand what they've built.

That's the most important lesson I'm taking away from the first day of this year's Kiss the Future AI Summit.