DEV Community: Fady

Can You Actually Build Real Software With Today’s AI Models?

Fady — Sun, 30 Aug 2026 06:01:26 +0000

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.

Securely Accessing Private AWS Resources from GitHub Actions with TailScale

Fady — Thu, 14 Dec 2023 09:49:49 +0000

The Problem

One of the common problems of CI/CD automation is how to handle private resources without exposing these resources directly to the public or relying on complex VPN setups may not be the ideal solution.

Typically, you go with something like OpenVPN, but OpenVPN can be complicated, with something like OpenVPN,you have to set up your own server, and configure, maintain, etc. On the other hand, it takes less than 2 minutes to set up TailScale, Another thing, if you live in a country where OpenVPN is blocked, you don't have many options.

Here is the diagram that we are going to be implanted in this blog, the blog post will guide you with step-by-step through its implementation. The initial steps involve setting up a GitHub Actions workflow that installs the TailScale client and authorizes it into a TailScale network. Subsequently, the blog post will cover the creation and configuration of the TailScale router, ensuring proper traffic routing and security group settings on AWS.

Connecting GitHub Actions to the Tailscale Network

Before starting this guide, you'll need to have a Tailscale network set up and configured with at least one existing device, If you do not know how, follow this guide and of course you're going to need an AWS account as well.

Now the next thing that I'm going to do is go out to GitHub and create a new repository,You can find the code for the end result in this repository.

You will then need to create an OAuth client to use with the Github action via this link, copy the Client ID and Client Secret to a safe place for now.

Go to the GitHub repo you created earlier and go to Settings > in the Security section of the sidebar, select Secrets and Variables, then click Actions, Create a GitHub secret with the name TS_OAUTH_CLIENT_ID and assign your OAuth client ID as the secret value and name TS_OAUTH_SECRET and assign your OAuth client secret as the secret value.

You will then need to create a server role account using ACL tags in Tailscale, basically ACL tags allow you to assign an identity to a device that is separate from human users, and use that identity as part of an ACL to restrict access. This should be used when adding servers to your Tailscale network, to learn more about ACL tags, click here

Open your favorite editor and create a .github directory and underneath .github we'll create a Workflows directory, this is the special directory that GitHub Actions is going to look for workflow files in, create a new workflow, I'm going to call it tailscale.yaml.

And inside of this file, we're going to go ahead and set up our basic workflow structure.

on:
  workflow_dispatch:
  push:

jobs:
  deploy-via-tailscale:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Tailscale
      uses: tailscale/github-action@v2
      with:
        oauth-client-id: ${{ secrets.TS_OAUTH_CLIENT_ID }}
        oauth-secret: ${{ secrets.TS_OAUTH_SECRET }}
        tags: tag:ci

Let me break it down for you.

the workflow dispatch event. Allows us to trigger workflows manually, which is great for debugging.
The push event means that whenever we push a change, it goes ahead and triggers a build.
Define the job and name it deploy-via-tailscale. It will run on the latest release of Ubuntu.
connect to your tailnet by using the Tailscale GitHub Action

Go ahead and push the code to Github, you should see an ephemeral node. The node can access nodes in your Tailnet, subject to the access rules that apply to the specified ACL tag(s).

Set Up Amazon VPC and Tailscale Router

What we're going to do is we're going to create a VPC, and then we're going to have this public subnet, and we're going to put an EC2 instance on that public subnet, and we're going to have that EC2 instance connect out to our Tailscale network as well, and then we're going to set that EC2 instance up as a router.

Let's go to the AWS Management Console. First, we'll create an elastic IP and EC2 instance on the public subnet, which will act as a subnet router.

After the instance has passed the checks we need to download and install Tailscale onto your subnet router machine.

Step 1: Install the Tailscale client

ssh into the instance and follow the instructions

curl -fsSL https://tailscale.com/install.sh | sh

Step 2: Enable IP forwarding and Advertise subnet routes

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

sudo tailscale up --advertise-routes==10.0.16.0/20 --accept-dns=false

Replace the subnets in the example above with the correct ones for your network, it will give you a link that you will need to go to in order to authenticate.

The EC2 instance should appear in the Tailscale console.

Step 3: Enable subnet routes from the tailscale console

Locate the device that advertised subnet routes, from the ellipsis menu at the bottom of the table, select Edit Route Settings. This opens the Edit Route Settings panel.

Everything should be working to test connectivity, we will add test connectivity to the Github action, commit and push the code.

on:
  workflow_dispatch:
  push:

jobs:
  deploy-via-tailscale:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Tailscale
      uses: tailscale/github-action@v2
      with:
        oauth-client-id: ${{ secrets.TS_OAUTH_CLIENT_ID }}
        oauth-secret: ${{ secrets.TS_OAUTH_SECRET }}
        tags: tag:ci
    - name: test-connectivity
      run: |
        ping -c 10 100.73.32.96

Replace the IP address with the IP address of the subnet router.

Create Private Amazon RDS Instance and Test Connectivity

After reviewing and verifying, we will provision an Amazon RDS instance in our VPC and test connectivity from our GitHub Actions workflow.

First, we will create a security group that will allow connection from the subnet router, I'm going to call it the database security group.

In a production environment, it is bad practice to allow all connections from a security group, Only allow access from trusted sources for specific ports and protocols, following the principle of least privilege.

I will not cover how to create an RDS database here. I assume you have already created an RDS database, please refer to the AWS documentation if you don't know how to create one.

If you want to test connectivity between your machine and the private Amazon RDS instance type the following command. This action allows you to connect to the MySQL DB instance using the MySQL client, Replace endpoint with the DB instance endpoint (DNS name) and replace admin with the master username you used. Enter the master password that you used when prompted for a password.

mysql -h endpoint -P 3306 -u admin -p

If everything is configured correctly, you should be able to see this massage.

We will return to the Github action workflow to test connectivity, we will create three secrets for the database endpoint, password, and username.

Update the workflow with this to test connectivity. We can now connect to RDS from any node in the Tailnet, using the same DNS name used inside AWS.

on:
  workflow_dispatch:
  push:

jobs:
  deploy-via-tailscale:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Tailscale
      uses: tailscale/github-action@v2
      with:
        oauth-client-id: ${{ secrets.TS_OAUTH_CLIENT_ID }}
        oauth-secret: ${{ secrets.TS_OAUTH_SECRET }}
        tags: tag:ci
    - name: Test-Connectivity-to-AWS-RDS
      run: |
        mysql -h ${{ secrets.ENDPOINT }} -u ${{ secrets.USER }} -p"${{ secrets.PASSWORD }}" -e "show databases;"

Conclusion

In this blog, we've demonstrated how to create a secure and seamless connection between GitHub Actions workflows and private AWS resources. This approach not only improves the overall security of your CI/CD pipeline, but also ensures that sensitive data and interactions remain within your network, TailScale is easy to use, and has robust encryption mechanisms.

This is not sponsored or endorsed by TailScale, I use the TailScale at work and in my home lab, I am just a happy customer.

One more thing, you can host Tailscale Control Server yourself if you want, which is a plus.

Protect your Web Apps Against DDoS Attacks by Using AWS Shield

Fady — Mon, 24 Apr 2023 09:52:09 +0000

AWS offers really great tools to protect you from threats and ensure security in the cloud, one of these tools is AWS shield which is essential tools to safeguard your web apps or websites from Distributed Denial of Service (DDoS) attacks.

what is DDoS attacks?

DDoS attacks have become increasingly common in today's digital world, with the number of attacks are rising, DDoS stands for “Distributed Denial-of-Service” attack, DDoS attacks are a type of Cyberattacks in which the attacker (Often, it's not just one person who is responsible for this attack; sometimes, the attacker is a nation) floods a server with internet traffic by botnets (A botnet is a network of computers infected by malware that are under the control of the attacker), rendering connected online services and sites inaccessible to legitimate users. These attacks are sophisticated and designed to overwhelm the network with unwanted traffic. As a result, network performance is either degraded or critical infrastructure experiences a service outage.

AWS Shield

AWS Shield is a managed DDoS protection service offered by AWS, It works in partnership with ELB, Amazon CloudFront, and Amazon Route 53 to protects you from DDoS attacks of many types of DDoS Attacks.
AWS Shield protects against three different types

Network volumetric attacks

These are designed to simply overwhelm the system being attacked.
So to direct as much raw network data at a target as possible

Network protocol attacks or TCP SYN floods

There are various types of protocol attack, but one common one is to generate a huge number of connections from a spoofed IP address (computers infected by malware) and then just leave these connections open and never terminating them, the server will be impacted by the huge volume of fake connections.

Application layer attacks

Imagine you have a part of your web app which allows searches, think of something like Facebook or Twitter Search which lets you search for new friends or people to follow, Attackers can use web app searches to launch DDoS attacks by sending a large number of requests to a web application that has a search feature. The attacker sends requests that are designed to consume as much server resources as possible. And it can be done hundreds, thousands, or millions of times per second. Some parts of the application are cheap to request, but expensive to deliver the result.

So those are the types of things which Shield protects against.

AWS Shield comes in two forms, Shield Standard and Shield Advanced. While both offer protection against DDoS attacks, there are significant differences between the two.

Shield Standard

Shield Standard is a free service that comes with all AWS accounts, you benefit from its protection automatically without you having to do anything.

AWS Shield Standard doesn’t provide much in the way of proactive capability or any form of explicit configurable protection. It’s just there working away in the background

Shield Standard is designed for applications that require basic protection against DDoS attacks but have a low risk tolerance.

Shield Advanced

Shield Advanced, which comes with additional costs (it costs $3,000 US dollars per month,per organization) and benefits, is a commercial extra product that offers additional detection and mitigation against large and sophisticated DDoS attacks, near real-time visibility into attacks, and integration with AWS WAF, a web application firewall.
Shield Advanced provides a 24/7 to AWS Shield Response Team (SRT), advanced attack mitigation techniques, and protection against attacks at the application layer.
It also includes features such as traffic logging and metrics, which allow customers to monitor their traffic and identify potential attacks.

Shield Advanced is designed for applications that require a higher level of protection against DDoS attacks and have a higher risk tolerance.

If you have feedback about this blog post, submit comments in the Comments section below.