At HowdyHack 2025, my team had a frontend that seemed to work, a backend that seemed to work, and an application that did not.
We were building a fitness app that would let someone upload a video of an exercise, analyze the movement, and return feedback on their form. I worked on the frontend, while a teammate worked on the backend and computer vision. We were making use of Kiro, AWS's agentic coding IDE, and because agentic coding was still new to us, we assumed the difficult part was generating the individual pieces. Once those pieces existed, connecting them felt like something the agent could handle for us.
When Two Working Pieces Do Not Make a Working System
I pulled the backend branch into the codebase with my frontend and told the agent to connect them. The first attempt failed. We changed the prompt and tried again, then kept doing roughly the same thing for far too long.
Looking back, we were playing a kind of prompt lottery. Instead of improving our understanding of the system, we kept hoping the next generation would produce the missing answer.
We had never properly decided where uploaded videos would live, how preprocessing would work, how the frontend would send a video to the backend, what the backend would return, or whether we needed a database. Sometimes we could get the upload closer to working, only to find that the analysis could not make its way back to the frontend. We were trying to debug an implementation before we had agreed on the architecture.
Near the end, I think we came closest to making progress when we started rebuilding the backend inside a codebase that already had access to the frontend. By then, the clock was running out. We had been awake for almost 24 hours, and we had no working product to present.
We failed the hackathon.
I am glad we did. I was not going to understand how to work effectively with coding agents the first time I used them, and that failure forced me to see a problem I probably would have missed if the demo had barely worked.
Productivity Is Not Competence
The lesson I took from that weekend was larger than "plan out your APIs first."
AI coding is another increase in the level at which developers can work. The syntax matters less when I can describe a feature and have an agent implement much of it. That gives me more time to think about requirements, architecture, edge cases, interfaces, and testing.
It also makes it easier to produce a large amount of code without understanding the decisions inside it.
AI can make you productive without making you competent.
If I cannot explain why a piece of my system exists, what assumption it depends on, or where I would look when it fails, I have given up ownership of the decision. The code may still work for a while. The problem appears when it stops working and my only debugging strategy is another prompt.
How I Build With Agents Now
If I rebuilt that fitness app today, I would start with the whole system rather than two independently generated halves.
- Define the product before the implementation. My team would agree on the user flow, the core features, and what we are intentionally leaving out.
- Research the engineering choices. I would use AI to compare libraries, frameworks, and approaches for tasks such as pose detection, video processing, and storage. AI is extremely useful for research, provided I still make and understand the decisions.
- Prove the smallest complete system. Instead of partially supporting push-ups, sit-ups, and several other exercises, I would first make one push-up flow work from video upload through analysis and feedback.
- Expand from a shared baseline. Once the frontend and backend work together, that version goes on the main branch. Team members can create feature branches from the same working foundation, then merge and test continuously.
- Review what the agent builds. I use AI to generate tests, inspect logs, resolve merge conflicts, and suggest debugging paths. I also read the code and ask the model to explain anything I do not understand.
This approach also gives every member of a team meaningful work. At HowdyHack, dividing the project into "frontend" and "backend" left our other teammates with relatively little engineering work while we struggled with integration. Starting from a working baseline would have let us split by features instead, increasing overall productivity.
What Changed for Me
I now use this process on work that is much less forgiving than a hackathon prototype.
While working on Finch's job-priority ranking, for example, I could have asked an agent to "build a better matching algorithm." Instead, I first had to decide what better matching actually meant.
A recently posted job may seem like a strong opportunity, but recency means very little if the user is not eligible for the role. A high resume match can also be misleading if the position does not support sponsorship and the applicant requires it. Those are product decisions before they are implementation details.
I used AI to research possible scoring factors, challenge the logic, consider drawbacks, and turn the resulting decisions into an implementation plan. The final system considers factors such as eligibility, fit, recency, and network signals, then gives users explanations for the ranking. After the implementation was generated, I reviewed the code and asked for explanations where I needed them.
That is the role I want AI to play in my engineering work. It can research faster than I can, generate code faster than I can type it, and help me inspect problems from several directions. I still need to own the reasoning that gives those capabilities direction.
AI will write more of the code I work with over time. That makes good decisions more valuable.
The engineer who benefits most will be the one who still knows what should be built, and can tell when the machine got it wrong.