I went for the conversations, not the talks

On October 1, I went to AI Lat, invited by Axel Abulafia, my teacher for the Startup course at ORT TIC, who was also a speaker and organizer of the event. I went with Guido Jacofsky, Lucas Waisbaum, Jose Barcelo and Benyi Sagranichne.

We arrived early and stayed until the afternoon. I attended a few talks: I had mainly gone to meet people and have conversations.

From a pitch to a conversation

Two days earlier, we had presented Gemm at the Parque de la Innovación. Restoman had also recently launched at Bibi’s. I had two projects to talk about, but also recent experiences that went beyond explaining what each product does.

At the Parque de la Innovación, we had needed to summarize Gemm in a few minutes, with a prepared presentation and limited time. At AI Lat, I did not have to fit everything into a pitch. A conversation allowed us to focus on one part of the project, explain the problem we wanted to solve and hear what the other person was working on.

That exchange interested me more than repeating a presentation. Stepping outside the environment where we develop our projects also helps us think about them in a different context: not just what we build, but who it could help and why.

Another contact for Gemm in Oil & Gas

Gemm was already focused on Oil & Gas. We were in contact with YPF and had visited the refinery to learn about the sector’s challenges.

At AI Lat, I spoke with some people who were interning at a company looking to implement automation and AI in that market. I told them about Gemm, and they were interested in the project.

It was not a change of direction for Gemm, but another useful contact in the market we were already targeting.

What I took away from Santiago Marro’s talk

I also attended Santiago Marro’s talk, “When agents write the code.” I took away several ideas about organizing work with AI beyond asking it to write code.

Clarify the context before implementing

One recommendation was to let the agent ask questions before starting and answer with as much context as possible. Rather than waiting until it finishes to discover it understood something different.

He also suggested that if the same clarification needs to be repeated three or more times, it should become a skill. The instruction no longer depends on remembering to write it in every conversation.

Tests first, not extra code

Another idea was to think about how a feature will be tested before choosing its implementation: write the tests first and ask for the minimum code needed to pass them. Tests need to cover behavior and business logic, not just whether the code compiles.

That also means reviewing the tests themselves. Having everything green means nothing if the agent deleted a failing test instead of fixing the problem.

Complete features and a separate review

Santiago proposed organizing work around features that function end to end, rather than building huge layers and integrating them only at the end. I did not understand that as a ban on layers: a feature can contain layers too. The difference is in how the work is divided and delivered.

For review, he recommended a new session, separate from the one that generated the code, along with small PRs and commits. Changing sessions does not guarantee an unbiased review, but it keeps the entire review from depending on the same context that produced the implementation. The final decision remains human.

Measure what happens after delivery

He also proposed looking at how much code needs fixing or reworking during the 21 days after delivery, rather than measuring productivity only by lines of code or the number of commits.

I took these ideas as criteria for reviewing how I work with agents, not as a process I had already implemented in full. Generating code is one part: defining what it needs to do, testing it and reviewing what gets delivered is still engineering work.

Bringing something back to the projects

I left with another contact for Gemm and several ideas for reviewing how I work with agents. The conversations helped me talk about what we are building; Santiago’s talk helped me think about how we build it.

For Gemm, talking to people looking to apply automation and AI in Oil & Gas was a way to keep getting closer to the market outside our usual environment. It was not just about showing the robot: the context where it could be useful mattered too.

And for working with agents, I left with concrete questions: is it clear what a feature needs to do before I ask for its implementation? Do the tests check that behavior? Am I looking at how much needs fixing afterward, or only how quickly the code was generated?

That is what I went to AI Lat for: to step away from development for a while, talk to people working on other projects and bring something back to my own.