Tobi Obitayo

Hi, I'm an undergraduate studying computer science at Georgia Tech, where I TA for a course on Privacy, Tech, Policy and Law. My work sits at the intersection of building things and thinking carefully about what those things do in the world.

My background is in software but my interests keep pulling toward the edges of it, specifically how technology shapes access, accountability, and learning. That tension is what got me into ethics in computing, and it's what keeps the work interesting beyond the coursework.

Lately I've been focused on taking small, well-scoped ideas and figuring out how to make them useful to other people, whether that's a visualizer that helps a student finally understand a hard concept, or a tool that solves a problem I kept running into myself. If any of that sounds familiar, I'd love to connect.

Powerless in the Driver's Seat

I booked a Waymo in four minutes. It arrived in four minutes. I unlocked it from the Uber app, got in the back seat, and a voice welcomed me by my first name. The whole thing felt pretty seamless and professional. A tutorial video played as the car started moving, teaching me what to do during the ride. I watched the steering wheel turn on its own in awe. After two minutes, surprisingly, I felt comfortable enough to stop paying attention to the road. That first ride was a very good presentation of Waymo's objective. Just me and a car that seemed to know exactly what it was doing. I even discovered a forgotten set of keys in the backseat from the previous passenger, which Waymo's external speakers helpfully reminded me about before I left, assuming those to be my keys. Small details like this made me impressed with the level of innovation happening in front of my eyes.

However, just three rides and something shifted. I was running late to an event, and the Waymo was taking me around campus instead of toward my destination. The most direct route had a blocked-off section of road, so the car was trying to navigate around it. I could see the block was temporary, and if a human driver were taking me, I would have said, just drop me at the nearest point, I'll walk from there. Instead, the Waymo insisted on reaching my exact destination. It kept trying to turn right onto the blocked road. The car wouldn't accept that the road was, in fact, blocked. At some point, a police officer came over to the car, probably to tell "us"¹ to move along or find a different route. The officer was waving at "us" to move along, speaking to the vehicle in hopes it understood what "straight" meant, clearly trying to help redirect the vehicle. But the Waymo just kept trying to turn. The cop kept signaling. This dance went on long enough that the officer eventually gave up and moved the barrier to let the Waymo through. I was a passenger watching an algorithm do what it was programmed to do, and I was completely powerless to stop it or explain the situation. The moment I unbuckled my seatbelt to get out, the car stopped and alerted me to call for support if I wouldn't buckle back up. I sat there, feeling trapped, unable to leave a vehicle that wouldn't listen to reason.

A police officer had to physically move a barrier because a car wouldn't adapt.

When I started using Waymo, I was drawn to the promise they represent: a technology designed to remove human error, to save lives from drunk driving, distraction, and exhaustion. Those are real problems. Thousands of people die every year in car accidents caused by human negligence. Removing that risk sounds almost obviously good. But in that moment on the blocked road, I realized something else was happening. The algorithm made a decision and committed to it. It couldn't interpret the context, and it couldn't see that the barrier was temporary or understand that a passenger might have different priorities. I could not talk to it or give it more context. It just kept trying the same thing, over and over, because that's what the data told it to do. Humans see a blocked road and adjust. We notice a police officer trying to help us and recalibrate. We understand that sometimes the perfect solution isn't worth the cost of getting it. We make calls based on context, in the moment, on things that don't fit into a predetermined set of rules.

What's harder to sit with is that this matters differently depending on who you are. I was uncomfortable and late to an appointment. I had the option, however limited, to complain about the experience. I could write about it and I could choose not to use Waymo again. The pedestrian on the street corner didn't get any of those choices. Neither did the police officer who had to intervene. They didn't choose to interact with an algorithm that couldn't adapt. They were just in the environment where this machine was learning to drive, and they had to trust that someone, somewhere, had made good decisions about what it would do when things got confusing.

Let me be clear: I believe that Waymo will improve and I am very excited for the future of autonomous cars, and perhaps I was simply unfortunate in this experience, but I keep thinking about trust. When I get into a Waymo, I'm consenting to a kind of algorithmic decision-making I don't fully understand. But pedestrians walking down a street can't consent. They're just trusting that the technology was built safely. And that trust feels lopsided when the algorithm can't think in real time the way a human can. Look at the technology around you. What does trusting it look like for you?

The State of Hackathons

I just completed my first hackathon, and here is how it went. This hackathon was hosted by the Claude Builder Club at Georgia Tech. Unlike a traditional 24 or 36-hour time frame for a hackathon, this one was just 3 hours. Claude being in the club's name meant it would be the central theme. I joined a random team of five other people. Before beginning, they released the prompt that would serve as the theme of the hackathon. Simply put, build a food-health app that more effectively engages users in healthier behaviors, including, as an example, a feature that could be a personal coach. My team started talking about how we could make the basic premise very unique because the prompt was a bit structured, and there were close to 40 teams competing. As we were listing out multiple features, we realized that creating a pet or mascot that serves as a mirror of the status of your health for the day was the angle we could take.

As a team, we split up with two, one group working on more of a roadmap, myself and one other teammate just coming up with a framework and seeing Claude's initial output, and the last two working on the pet design, as it was quickly understood that the user interface (UI) would need to be top-notch to also help us stand out. This was mostly the process for the three hours, and as we neared completion, we had a working prototype built and a pitch made. We built the app in React with code setup to integrate the Claude Vision Application Programming Interface (API) and Apple HealthKit API to get the data. Our demo pitch included all the information, plus a live demo of the judges using the app.

On the Format

After that introductory walkthrough, here are my thoughts. My team did not win during the competition, and there are a couple of items of feedback I would give for the hackathon, plus a couple of thoughts to consider as we progress with the notion that these are how hackathons are evolving. With the time being only 3 hours, I understand making the prompt more one-dimensional so judging can be relatively similar across the many submissions, but this prompt did not seem to really connect with what can be done with the tools given, nor was it connected much to the ones who gave the prompt, which was NBC. I realized that I was not really invested that much in the idea. I understand that this might not be the point of this type of hackathon, but as someone who wants to make tools that can innovate or make quality tools to improve the experience of a user, I just felt like this prompt failed to trigger this sense I had.

Now I will say there were some very clever ideas, and it has gotten me to think outside the box when faced with a problem-solving time, but my point stands about the lack of creativity from this prompt. I really enjoyed many aspects of the hackathon, meeting with my group, and just getting to know them better.

Shipping Fast vs. Learning Deep

Lastly, I want to talk about the state of hackathons from my perspective. As might have gone through your mind, what actually is happening during these hackathons? Well, from my perspective, there wasn't much actual learning. Shipping fast is the name of the game, and much of this was simply waiting for Claude to finish outputting and start the next prompt. The API implementation was not working properly during the demo due to the time crunch and what needed to be fulfilled in the presentation. Projects, I have been told, can really help one stand out when in the employment process, but all these taught me was creating solutions and implementing rapidly (as a skill that is worth value but cannot stand in for pure technical abilities).

I am not saying that Claude and tools like this are not the future because I can clearly see their use and potential, I am just saying for learning anything technical this is not the spot to do that, which meant that when my usage ran out during the hackathon, I had to stop monitoring Claude's generated code because typing by hand was going to be insufficient. I wonder what companies of these large language models (LLM) and coding agents have their engineers do since they probably use AI to help build these products. I assume what separates them is the responsibility of knowing what is being generated and being able to speak up if a problem arises. Some fixes that could improve on this genre of hackathon is having engineers reviewing code quality to help young builders steer in the right direction.

Overall, my mindset from this hackathon has shifted to being able to understand my personal projects code because these are ideas I started with passion and because prompting is for everyone, but knowledge is for those who desire it.