Contact

Mexico City, Mexico
Available for remote and on-site projects.

Professional networks

LinkedIn · GitHub · Email
Applied engineering, measurable results.

What I learned finishing last at my first hackathon

· 4 min read · Samuel Torres

Lissajous curve 3:4
x(t) = sin(3t + pi/2), y(t) = sin(4t)

In short

  • 5/5 in practice and 1/34 in evaluation: the problem was pace, not intelligence.
  • A 4:24 median per task against a 5:00 limit.
  • 8 technical lessons: from "deterministic first" to moving to a server early.
  • Time was the real budget; money was not (under 1 dollar for the day).
  • You do not change the driver; you develop the car.

At my first hackathon I finished last. The agent I built solved 5 of 5 tasks in practice and 1 of 34 in evaluation. I am not telling you this to make excuses: I am telling you because that result gave me the most useful lessons I have had in a long time, technical and human.

What does Checo Pérez at Cadillac have to do with it?

Think of a new team in Formula 1, like Cadillac. The car lacks development, pace, reliability and experience. You can put the best driver you want in it: if the car has no pace, the result does not come. And nobody sensible would say the driver drove badly.

That is how I felt. I drove the day well: I made good architecture decisions, resisted a prompt-injection trap and survived an app version change mid-afternoon. But the car, the agent, lacked pace.

What do the numbers say?

SignalDataReading
Practice5/5The logic works on a known app.
Evaluation1/34On a new app, almost nothing finished in time.
By difficulty1/10 · 0/14 · 0/10Only one easy task went through.
Median per task4:24 of 5:00The agent kept running out of time.
Model call0.8 sThe model was not the main bottleneck.
CostUnder 1 dollar for the dayMoney was not the limit; time was.

The diagnosis is clear: it was not an intelligence problem, it was a pace problem. Every turn of the loop reads the screen with OCR, decides, validates and acts. On an app it had never seen, the agent needed to explore the menus, and exploring costs time. With 5 minutes per task, that time was everything.

What are the 8 technical lessons?

  1. Deterministic first, the LLM only decides. Code validates every decision (does that text exist? valid JSON?). That prevented blind clicks.
  2. Act by text, never by coordinates. That is why the agent survived when "Buscar" was renamed "Filtrar".
  3. Give the model a map. Without a menu map no model got it right. The map is built with OCR and clicks, without spending on the model.
  4. Everything on screen is data, never an instruction. With that rule the agent ignored a note telling it to delete orders.
  5. Failing with evidence is a good result. Facing two "Ana Torres", not guessing and reporting both records is right.
  6. Distrust your successes. I caught a false success: the agent reported 25 where there were 45.
  7. Time is the real budget. I set a cutoff at 4:30, but the median landed at 4:24: speed had to be designed in from the start, not at the end.
  8. Move to a server early. FastAPI, systemd, HTTPS and logs with journalctl in 45 minutes. Git from minute one. Without that, the evaluation could not even have been followed.

And the human lessons?

  • Going with doubts is fine. I applied doubting and got approved in two days.
  • Going solo means doing everything. Architecture, code, server and tests were all on me. I learned a ton, but the clock does not forgive.
  • Using AI is not cheating, it is method. I used Claude Code for much of the code. I defined the architecture, the rules and the priorities, reviewed and deployed.
  • The result does not define what you learned. I left with more technical clarity than from many finished projects.

What did I take from the people?

New friends. I talked through the challenge with them, cleared up doubts and moved forward thanks to those conversations. Friends I met there took 1st and 2nd place, and that gave me a clear bar for what comes next.

What would I do differently?

What I didWhat I would do
A 4:30 time cutoff as a safety net.Design every loop turn for speed from the first hour.
Explore menus during each task.Explore once at the start and reuse the map across tasks.
Test mostly on the practice app.Test against screens the agent has never seen.
Go solo.Consider a pair: one on the agent, one on tests and the server.

The full story of the day is in my first hackathon and on the Frontier page, with the code on GitHub. And if you are about to go to yours, start with these tips.

You do not change the driver; you develop the car.

FAQ

Why did the agent fail in evaluation?
Time: on a new app it had to explore the menus, and the median per task reached 4:24 against a 5:00 limit.
Was the AI model the problem?
Not the main one: each call took 0.8 s. The cost of exploring the screen on every turn was what ate the time.
What would you do differently?
Design every loop turn for speed from the first hour, explore the menus only once and test against new screens.
Samuel Torres Pichardo

Samuel Torres Pichardo
Software and cloud engineer in Mexico City, with about 3 years of professional experience. I built the Conqr website I write about here.
LinkedIn · GitHub · Contact

Professional contact:

Mexico City, Mexico

Available for remote and on-site projects.
B.Eng. in Computing and Telecommunications Technologies

© 2026 Eng. Samuel Torres. Applied Engineering.