What I took from the Astra AI × Vercel AI Developer Summit

Why I went

Astra AI was already familiar to me before the summit: I had used it while I was still in high school. When Maj Korent and I saw that Astra AI and Vercel were organizing their first AI Developer Summit in Ljubljana, we decided to attend. I wanted to see the people and engineering behind a product I already knew, but I was even more interested in Vercel's approach to AI-native software development.

I did not arrive with a polished theory of what the event would be. I only knew that it was intended to be technical, which was exactly the reason I wanted to go. I already use agents, automation, and structured development workflows in my work, so I was looking for concrete patterns I could compare with my own systems rather than another overview of AI trends.

Maj and I work on quite different projects. That made our discussions after the talks more useful: the same engineering pattern could lead each of us toward a different application. We were not trying to copy one stack. We were trying to identify practices that would survive outside the event.

I was not discovering agents; I was studying the system around them

Lars Grammel's presentation on AI SDK software factories was the part that stayed with me most. The important point was not simply that agents can write code. I already work with agents and automated workflows. What I found valuable was how explicitly the factory separated responsibilities, states, review loops, and human gates.

One example was a ticket-solving workflow that begins with an issue, classifies it as a bug, feature, or documentation task, and then follows a specialized path for analysis, implementation, review, revision, and human approval.

That structure gave me an immediate improvement for my own process. For feature requests, I want an additional human checkpoint after the agent completes its analysis and before implementation starts:

I do not want that checkpoint because the agent necessarily needs help. I want it because this is the best moment to add domain context, challenge the first interpretation, change the scope, or find a better architectural direction before code exists. Review after implementation catches defects; review after analysis can prevent the wrong implementation from being built at all.

The operating loop matters as much as generation

The software-factory model also made me look beyond implementation. A useful system needs a deployment process, review loops, automated maintenance, monitoring, and documentation that stays connected to the software as it changes. Generating a patch is only one state in a much larger lifecycle.

This aligns with the direction I am already taking, but it exposed places where some of my own steps are still implicit. If a workflow depends on a person remembering when to verify, document, observe, or recover a change, then the workflow is not fully designed yet. The event gave me a clearer vocabulary for turning those expectations into explicit stages and contracts.

Scaling Astra made the infrastructure concrete

Tjaž Silovšek's talk shifted the discussion from agent workflows to the operational reality of scaling Astra AI. One example I noted was the use of AWS Database Migration Service and logical replication as part of a database migration strategy. The interesting part was not the name of the tool; it was the surrounding work: full loads, change-data capture, validation, schema and sequence synchronization, and replication-lag monitoring.

That is a useful reminder that “scaling” rarely means adding more servers. It also means designing migrations that can be observed, verified, and recovered. Capacity, data correctness, failure handling, and operational discipline have to move together.

My interpretation of the 100× engineer

The panel with Tjaž Silovšek and Boris Besemer connected with something I have been thinking about for some time. A strong model does not automatically make someone a 100× engineer. The leverage comes from combining capable agents with good workflows, architecture knowledge, verification, and the judgment to know when a human should intervene.

Curiosity is part of that capability. AI development moves quickly enough that a developer who stops testing tools, comparing approaches, and learning from failures can fall behind even while using a powerful model. For me, the goal is not to automate the maximum possible amount of work. It is to increase the amount of high-quality work I can complete without weakening ownership or evidence.

It was also valuable to hear Guillermo Rauch's perspective as the person leading Vercel. His contribution placed the individual workflow patterns inside a broader change in how developers design, deploy, and operate software.

What changed for me after the summit

“The useful part was not seeing an agent write code. It was seeing the surrounding workflow made explicit.”

• I will update my ticket workflow first, with clearer task classification, specialized paths, revision loops, and a human ideation gate before feature implementation.
• I will make deployment, review, maintenance, monitoring, and documentation responsibilities more explicit instead of leaving them as informal expectations.
• I will keep autonomy bounded by risk: an agent may execute a narrow task, but evidence and human responsibility remain part of the release decision.
• I will continue evaluating platforms such as Vercel for what they remove from the operational burden, while separating platform convenience from architectural lock-in and cost.

The best outcome was not a list of products to adopt. It was leaving with a specific process I wanted to change. The summit gave me useful language for work I already value: architecture over novelty, evidence over confidence, and controlled autonomy over uncontrolled speed.

I am grateful to Lars Grammel, Tjaž Silovšek, Boris Besemer, Guillermo Rauch, and the Astra AI and Vercel teams for showing how these systems are being built and operated in practice.