Since around 2014, I’ve had a habit of browsing Hacker News every day to see what people were building and what new technology was coming out.
Since ChatGPT arrived, Hacker News has basically been taken hostage by AI.
Every week there is another story about someone building in a weekend what supposedly needed ten engineers before, or a new model that is going to change software development forever.
Every time I read one of those posts, I ask myself the same question:
How much of this is real, and how much is hype?
Around the same time, I found Google’s All Things Agentic Hackathon.
That seemed like a good excuse to test this properly.
I didn’t want to build another landing page or to-do app. I wanted a real frontend and backend, authentication, cloud infrastructure, storage, CI/CD, tests, security, AI agents, and enough moving parts for things to actually break.
The question was simple: Can one person use today’s AI models to build real software?
Finding Something Worth Building
Ironically, AI wasn’t very useful for finding the idea.
I spent around two hours talking to Gemini and ChatGPT, and most of the suggestions either already existed or were just weird.
So I went for a walk.
A few years ago, I had to record a video for a client explaining how to manage their WordPress site on AWS.
Recording it was easy.
Editing it was not.
The audio was bad, I had multiple takes, and I spent much longer than I wanted turning a simple recording into something presentable.
That gave me the idea.
What if I could upload the raw video and let an AI system handle most of what happens afterward?
Not just remove silence, but actually understand the footage, find bad takes, decide what should be removed, review the edit, render it, and eventually learn from how the published video performed.
That became Croviq.
I’m a DevOps engineer. Infrastructure, containers, networking, and CI/CD are comfortable territory for me.
Building a React application, a video editor, and a multimodal AI system from scratch is not.
So before writing much code, I used AI to help me design the product.
I gave the models the hackathon requirements, my constraints, and the basic idea. I wanted to stay inside Google Cloud, keep the cost low, and build something that could actually be deployed.
I also kept questioning the architecture instead of just accepting whatever the model suggested first, with some help from Matt Pocock’s AI skills.
What I Learned After Five Days of Building
So, can you build real software with AI?
I’m not going to turn this article into clickbait, so I’ll answer that now.
Yes.
But not in the way some of the headlines make it sound.
Writing code was actually one of the easier parts.
The models could generate a surprising amount of working code, often in frameworks and areas I don’t normally work in.
The problem is that they are also very good at telling you something is finished when it isn’t.
A feature can look completely fine in the code. The agent can tell you the tests pass and everything has been successfully implemented.
Then you open the browser and half of it is broken.
I also went into the project thinking the backend was going to be the hardest part.
Video processing is very backend-heavy, so that seemed obvious.
Surprisingly, the backend ended up being relatively easy.
The frontend was much worse.
Getting an agent to write a frontend that actually works, looks good, and behaves the way you expect is much harder than I thought.
Gemini was actually the best model I tried for frontend work.
I think its image understanding helps a lot because I could give it screenshots, show it exactly what was wrong, and let it work from there.
For general coding, though, I still found Gemini noticeably worse than OpenAI or Claude.
It would sometimes confidently generate something that was simply wrong or based on outdated information.
That becomes much more dangerous when an agent is changing hundreds of lines across multiple files, because now the bug is hiding somewhere inside a massive Git diff.
And if you don’t catch it, you can end up with some pretty nasty bugs.
I Stopped Looking for the “Best” Model
Eventually I stopped trying to find one model that was good at everything.
I started using them more like a small team.
An OpenAI model would act as the advisor and think through the problem first.
Gemini Flash would do most of the actual implementation.
Then another model would review the changes before I accepted them.
That worked much better than expecting one model to plan, write, review, and debug everything by itself.
It also changed the way I think about AI coding.
I don’t really care anymore about which model is “the best.”
I care about which model is best for the job I’m giving it.
Then I Started Thinking About Tokens
Another thing I started noticing was how easy it is to burn through tokens when you use coding agents all day.
I came across Daniela Baron’s post about running out of Claude tokens, and a lot of it sounded familiar.
The problem is not only how much code the model generates.
It is all the other stuff you keep feeding back into it.
Huge terminal outputs. Documentation. Tool definitions. Files it read twenty messages ago. Failed attempts. Conversation history that just keeps getting bigger.
A bigger context window sounds great, but it does not really solve the problem if you keep filling it with things the model does not need.
At some point I started asking myself:
Does the model really need this entire conversation?
Does it need the output of every command?
Does it need to read ten files when only two of them matter?
Giving the model less, but better, context started becoming just as important as choosing the model itself.
And I think this is something we are going to hear a lot more about.
The model matters, obviously.
But the harness around the model, the tools it can access, what context gets loaded, and how much garbage you keep out of that context matter just as much.
After five days of building Croviq, I don’t think AI removes engineering, If anything, it made some parts of engineering more important.
You still have to review what the models produce which is the hardest part, test it properly, think about security, and know when something just looks wrong.
Some tools that I used in the hackathon that are useful
if you are going to vibe code, you will need them both, I have been using GitGuardian and Betterleaks to scan for leaked secrets while the agents were changing a lot of files quickly. With AI generated code, this became a very useful safety net.
Oh My Pi was the sweet spot for me between heavier tools like OpenCode and building everything in the pi ecosystem. It stays lightweight, but still gives you a good ecosystem of pi plugins out of the box.
Matt Pocock’s AI skills were some of the most useful I tried. His workflow forces you to write the specs and understand what you are building before asking the agent to code, which makes a huge difference. If you and the agent don’t have a clear plan, things go wrong very quickly.
Impeccable gave me much better results for frontend work, especially when combined with native browser tools like Chrome DevTools and Oh My Pi. If you are doing frontend work with an agent, I would definitely read the documentation and use this skill properly.
RTK (Rust Token Killer) is great for reducing token usage from CLI commands. It sits between the agent and commands like git log, then returns a condensed version instead of dumping the entire output into the context. Simple idea, but it can save a lot of unnecessary tokens.
Thank you for reading this far!
I created this article for the purpose of entering in Google’s All Things Agentic Hackathon.
Top comments (0)