Forem: Fatih Şennik

AI-Written Code Is Only Better When a Skilled Programmer Is Holding the Wheel

Fatih Şennik — Wed, 20 May 2026 19:31:09 +0000

Originally published at fatihsennik.com

I'm going to say something that will annoy people on both sides of the AI coding debate.

AI-generated code is not good or bad by itself. It's a mirror. It reflects the skill level of the person using it and it does so at about three times the speed and ten times the volume. A skilled developer using AI writes better code faster. An inexperienced developer using AI writes worse code faster. The AI doesn't know the difference. It just outputs.

I've been using local models in my daily workflow for months now such any in LLM Studio, Ollama and so on. I've watched what it does to code quality when I use it versus when junior developers on client projects use it. The gap is not subtle.

What Actually Happens When a Junior Uses AI

Ask a junior developer to build a user authentication system without AI. They'll spend time reading the Laravel docs, look at some examples, make some mistakes, learn from them. The output will be imperfect but they'll understand it. They can debug it when it breaks.

Now give that same developer Cursor or GitHub Copilot. They describe what they want. The AI generates a complete auth system in thirty seconds. It looks professional. The tests pass. It ships.

Six months later that system has a session fixation vulnerability nobody noticed because nobody fully read the code. There's no CSRF protection on one of the token refresh endpoints because the developer didn't know to ask for it, and the AI didn't volunteer it. The password reset flow has a subtle timing attack vector.

None of this is the AI's fault, exactly. The AI generated plausible code for the prompt it was given. The prompt didn't mention security requirements because the person writing it didn't know those requirements existed. The AI can't tell you what you forgot to ask for.

This is the core problem. AI is very good at answering questions. It is completely useless at telling you which questions you should have asked.

What It Looks Like When a Senior Uses It

Here's what my actual workflow looks like when I use AI for a Laravel feature.

I already know what the feature needs. I've thought about the data model, the edge cases, the security boundaries. I know which Eloquent methods are injectable if misused. I know which middleware needs to be on which routes. I know what the failure modes are.

I use AI to generate the boilerplate the migration, the resource class, the form request skeleton. Stuff that's mechanical and correct-by-default. I review every line. I spot when the generated code makes an assumption I don't agree with. I change it. I add the validation rule the AI skipped. I move the authorization check the AI put in the wrong place.

The AI made me faster at the parts that didn't require my judgment. My judgment handled everything that mattered.

That's a completely different activity than what the junior developer was doing. It just looks the same from the outside both of us typed a prompt and got code back.

The Confidence Problem

What makes this genuinely dangerous isn't the bad code. It's that the bad code looks exactly like good code.

Handwritten junior code usually has tells. Inconsistent patterns. Awkward variable names. Missing error handling that's obviously missing. An experienced developer reviewing a PR can see the skill level of the author and calibrate their scrutiny accordingly.

AI-generated code has none of those tells. It's stylistically consistent. It uses the right method names. The error handling is there it's just handling the wrong errors in some cases. The structure follows conventions. It passes linting. It looks, at a glance, like it was written by someone who knew what they were doing.

That's the trap. Code review gets less rigorous because the code looks rigorous. Static analysis catches some of it — which is exactly why I started running Semgrep on every MR regardless of who wrote the code. But tooling isn't a full substitute for the reviewer understanding what they're looking at.

But AI Will Get Better

Sure. Models improve. Reasoning gets sharper. Context windows get longer.

But "better at generating code" and "better at generating secure, maintainable production code for your specific application's threat model" are not the same thing. The second one requires understanding your business logic, your deployment environment, your user base, your compliance requirements, and a hundred other things that live outside the prompt.

A model that can generate a theoretically correct authentication system still can't tell you that your specific application handles healthcare data and therefore needs specific protections the generic implementation doesn't include. You have to know that. You have to bring it to the prompt. And knowing what to bring requires exactly the kind of hard-won experience that AI is supposedly making unnecessary.

The people confidently saying "AI will replace senior developers in two years" are, in my observation, mostly people who haven't spent much time debugging AI-generated code in production. That experience has a way of clarifying your views.

What I Tell Junior Developers

Use it. It's a genuinely useful tool and pretending otherwise is just nostalgia dressed up as professionalism.

But use it like a calculator, not like an oracle. A calculator gives you the right answer if you set up the equation correctly. Set it up wrong and you get a confident, precise, completely wrong answer. The calculator doesn't know your equation was wrong.

Understand what the AI generates before you ship it. Not just "does it work" understand why it works and what happens when the inputs are different from what the AI assumed. If you can't explain a piece of generated code to a teammate, you're not done yet.

And build the fundamentals anyway. The developers who get the most out of AI tools are the ones who would be competent without them. The shortcuts are only useful if you know what you're shortcutting.

The Honest Bottom Line

AI coding tools are productivity multipliers. The problem with multipliers is that they scale whatever you already have skill and judgment as much as speed and volume. Give a skilled developer a 3x multiplier and you get excellent code, faster. Give an inexperienced developer the same multiplier and you get more code, faster, with the same proportion of problems as before except the problems are now harder to spot because the code looks polished.

The technology is not the variable here. The developer is.

I'll keep using AI in my workflow. I'll keep running Semgrep on everything it touches. I'll keep reviewing every line before it goes to production. And I'll keep being slightly suspicious of any team that's shipping faster than before but hasn't gotten noticeably better at knowing what to ship.

Speed without judgment isn't progress. It's just more surface area for things to go wrong.

How Misconfigured Docker Ports Bypass Every Firewall You Set Up - Stealthy vulnerability

Fatih Şennik — Sun, 17 May 2026 16:36:50 +0000

Originally published at fatihsennik.com

You were running your own servers. You thought you understood firewalls such as UFW rules, iptables, Cloudflare in front of everything. You'd done the reading. You knew what you were doing.

Then you set up Docker on a new server and watched it silently undo all of it.

This isn't a hypothetical. I found this the hard way, on a friend's server, after something was already listening on a port that had no business being open.

How It Started

The server was a fresh Ubuntu VPS. My friend had a Laravel application, a MySQL instance, a Redis cache, and a private admin panel they definitely did not want public. Standard setup. He had configured UFW before installing anything:

ufw default deny incoming
ufw allow ssh
ufw allow 80
ufw allow 443
ufw enable

Clean. Only ports 80, 443, and SSH open. He checked with ufw status and it looked exactly right. He ran nmap from my local machine against the server IP and the output confirmed it, three ports, nothing else.

Then He installed Docker, deployed the stack with Docker Compose, and moved on.

Three weeks later, a routine audit on their side flagged something in network logs. Traffic was hitting their server on port 6379. From an IP address in Romania. ⚠️

Redis. The cache that's supposed to be internal-only. Completely exposed to the internet. 😱

What Docker Does to Your Firewall

This is the thing that trips up a lot of people who come from a traditional server background. Docker doesn't treat nicely with UFW. It doesn't go through UFW. It goes around it.

When you map a port in Docker such as ports: 6379:6379 in your Compose file. Docker modifies iptables directly. It inserts its own rules into the DOCKER chain, which gets evaluated before the INPUT chain where UFW rules live. Your UFW deny incoming rule never gets a chance to fire.

The result: UFW says the port is blocked. ufw status says the port is blocked. But the port is actually open and accepting connections from anywhere.

You can verify this by running:

# UFW thinks everything is fine
ufw status verbose

# But iptables tells the real story
iptables -L DOCKER -n

You'll see entries like:

ACCEPT tcp -- 0.0.0.0/0 172.17.0.2 tcp dpt:6379

That's Docker accepting connections from anywhere (0.0.0.0/0) and forwarding them to the Redis container. UFW knows nothing about it.

This behavior is documented. Docker's official docs mention it. But it's buried, and most tutorials don't bring it up at all. So you follow a guide, set up UFW, feel secure, and then publish Redis or MySQL or your admin panel to the entire internet without realizing it.

What an Attacker Finds

Redis with no authentication which was the default for a long time, and still is if you don't configure it is one of the most exploited services on the internet. Shodan lists hundreds of thousands of exposed Redis instances at any given moment.

What can someone do with access to an unauthenticated Redis? More than you'd expect.

If it's a Laravel app, the session data is probably in Redis. Someone with read access to Redis can steal sessions and log in as any authenticated user by including your admin accounts without knowing a single password.

Worse: if the Redis instance has write access and the server is running as root or a privileged user, there are known techniques to write SSH keys into the authorized_keys file via Redis. At that point it's full server compromise, not just a data breach.

In my friend's case, the logs showed connection attempts and some key enumeration. We couldn't confirm with certainty whether sessions were read. We had to assume they were, force-logout every active user, rotate all credentials, and notify the affected accounts. Not a fun conversation to have.

The Fix: Bind to localhost, Not the World

The cleanest solution is to stop publishing internal services to 0.0.0.0 in the first place.

In your docker-compose.yml, any service that doesn't need to be publicly accessible should bind only to localhost:

services:
redis:
image: redis:7-alpine
ports:
- "127.0.0.1:6379:6379" # localhost only — not 0.0.0.0
command: redis-server --requirepass your_strong_password_here

mysql:
image: mysql:8
ports:
- "127.0.0.1:3306:3306" # same principle
environment:
MYSQL_ROOT_PASSWORD: your_root_password

The 127.0.0.1: prefix tells Docker to bind the host-side port only to the loopback interface. Docker still creates its iptables rules, but they only accept connections from localhost not from external IPs.

For services that don't need to be exposed on the host at all (Redis accessed only by other containers in the same Compose stack), just remove the ports mapping entirely and use Docker's internal networking:

services:
app:
image: your-app
depends_on:
- redis
- mysql
# No ports needed here for internal communication

redis:
image: redis:7-alpine
# No ports: mapping — only accessible within Docker network
command: redis-server --requirepass your_strong_password_here

mysql:
image: mysql:8
# No ports: mapping

Containers in the same Compose project can reach each other by service name (redis:6379, mysql:3306) without any host port mapping. There's nothing to expose.

Fixing Docker's iptables Behavior at the Engine Level

If you want UFW to actually control Docker traffic, there's a configuration option in the Docker daemon that stops it from touching iptables directly:

Create or edit /etc/docker/daemon.json:

{
"iptables": false
}

Then restart Docker:

systemctl restart docker

The problem with this approach: now Docker's internal container-to-container networking can break too, because Docker relies on its own iptables rules for routing between containers and for NAT. You'd need to manage that routing manually with your own iptables or nftables rules. For most people this creates more problems than it solves. So please ingore it.

The Audit You Should Run Right Now

If you have Docker running on any server, check what's actually exposed at the iptables level, not just what UFW thinks is exposed:

# See all open ports on the host (Docker and non-Docker)
ss -tlnp

# See specifically what Docker has added to iptables
iptables -L DOCKER -n --line-numbers

# Or just scan yourself from outside
nmap -p 1-65535 your.server.ip

That last one is the most honest. Run it from a machine outside your network and see what actually responds. If you see ports you didn't intentionally open, you have the same problem I found on that my friend's server.

Also check your Compose files for any service with a ports: mapping that uses only a port number or 0.0.0.0:


`# Find potentially dangerous port mappings in your Compose files
grep -r '"[0-9]*:[0-9]*"' /path/to/your/compose/files
grep -r "'[0-9]*:[0-9]*'" /path/to/your/compose/files`

One More Thing That Makes This Worse

The default Docker network (172.17.0.0/16) is also reachable from other containers, even across different Compose projects on the same host. If you're running multiple client applications on one server, a compromised container in one project can potentially reach services in another project if they're all on the default bridge network.

Use named networks and keep projects isolated:

networks:
internal:
driver: bridge

services:
app:
networks:
- internal
redis:
networks:
- internal

This won't stop everything, but it reduces the blast radius significantly if something does get compromised.

What I Changed After This

On every server where I deploy Docker now, my checklist before going live:

Run nmap -p 1-65535 against the public IP from an external machine
Verify every ports: mapping in every Compose file has 127.0.0.1: prefix or is removed entirely
Redis and MySQL never have host port mappings unless there's an explicit reason
All services that only talk to each other get put on a named internal network with no host exposure
Redis always runs with --requirepass even on internal networks

Most of this takes five minutes to get right. The problem is that most Docker tutorials skip it entirely, they show you ports: "6379:6379" and move on, and nobody mentions that you just published your cache server to the planet.

Run the nmap scan. Not later, now. It takes thirty seconds and you might not like what you find.

How to Install WireGuard VPN on Ubuntu and Configure It as a Server — Using Port 443 to Bypass ISP Throttling

Fatih Şennik — Tue, 12 May 2026 12:52:39 +0000

Originally published at fatihsennik.com

What is WireGuard VPN ?

WireGuard is a secure network tunnel operating at Layer 3, built directly into the Linux kernel as a virtual network interface. Its goal is straightforward: replace both IPsec and TLS-based solutions such as OpenVPN — and do it better. More secure, more performant, and significantly easier to use.

A cleaner mental model

At its core, WireGuard is built around a simple principle: a tunnel is an association between a peer's public key and a tunnel source IP. No certificates, no certificate authorities, no complex configuration hierarchies. If you've used OpenSSH, the model will feel familiar — short, static Curve25519 keys handle mutual authentication, and that's it. No central server required. it's peer-to-peer by design, though you can use a hub-and-spoke topology.

Fast handshakes, strong privacy

Session creation is handled transparently using a single round-trip key exchange based on the NoiseIK protocol — fast and invisible to the end user. The protocol provides strong perfect forward secrecy and a high degree of identity hiding, so even if keys are later compromised, past sessions stay protected.

Performance-first design

Data in transit is encrypted using ChaCha20Poly1305, a modern authenticated-encryption cipher that's fast even on hardware without dedicated AES acceleration. Packets are encapsulated in UDP, and the kernel-level implementation takes full advantage of Linux's queue and parallelism primitives. Crucially, WireGuard is designed to allocate no resources in response to incoming packets — a key factor in its resilience under load. So, it runs over UDP, which is faster than TCP-based VPNs but can be easliy blocked or throttled by some networks.

Better DoS protection

WireGuard improves on the IP-binding cookie mechanisms used in IKEv2 and DTLS by adding encryption and authentication to the cookie itself — making denial-of-service mitigation significantly more robust.

Small enough to audit

Perhaps the most striking aspect of WireGuard is its size: the entire Linux implementation fits in under 4,000 lines of code. Compare that to OpenVPN's ~100,000+ lines and the security implications become obvious. A smaller codebase means a smaller attack surface, and one that's actually feasible to audit and verify.

How to Install WireGuard VPN on Ubuntu and Configure it as a server.

1) Update packages and install WireGuard.

sudo apt update && sudo apt install -y wireguard

2) Generate server private and public key pair.

wg genkey | sudo tee /etc/wireguard/private.key

sudo chmod go= /etc/wireguard/private.key

sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key

3) View the generated private & public keys — you will need them in the WireGuard config.

sudo cat /etc/wireguard/private.key

sudo cat /etc/wireguard/public.key

4) Find your actual network interface name — it will be the one associated with your server's public IP such as ens160 and eth0.

ip a

5) Create your WireGuard server configuration file. You can name the virtual network interface anything you like, such as wg0.conf or custom-name.conf. Let's name it as name0.conf.

sudo nano /etc/wireguard/name0.conf

[Interface]
PrivateKey = Copy /etc/wireguard/private.key to here
ListenPort = 443
Address = 192.168.50.1/24

## Enable IP forwarding (for routing)
## Please check your network interface name such as ens160.
## Please check that -i name0 same as your config file name.

PostUp = iptables -A FORWARD -i name0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens160 -j MASQUERADE
PostDown = iptables -D FORWARD -i name0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens160 -j MASQUERADE

## Client 1
[Peer]
PublicKey = Paste your mac client's public key here.
AllowedIPs = 192.168.50.2/32

## Client xN
[Peer]
PublicKey = Paste your widows or any client's public key here.
AllowedIPs = 192.168.50.3/32

6) Enable IP forwarding in the kernel so that server acts as a router, passing traffic between your VPN clients and the outside network.

echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf 

sudo sysctl -p

7) Start WireGuard and enable on boot and verify the interface is up.

sudo systemctl enable wg-quick@name0 

sudo systemctl start wg-quick@name0

sudo wg show

8) If UFW is enabled, open the WireGuard port in the firewall.

ufw allow 443/udp

9) Every time you update the WireGuard configuration file, remember to restart the WireGuard service for the changes to take effect.

sudo systemctl restart wg-quick@name0

How to Install WireGuard VPN on Mac and Configure it as a client.

Install the official WireGuard app from the Mac App Store: Download

Click 'Add Empty Tunnel' in the app and paste the client config below. Make sure the client IP address (e.g. 192.168.50.2/24) matches the AllowedIPs value set for this peer in your server's /etc/wireguard/name0.conf.

[Interface]
PrivateKey = This is auto generated. Do not share it with anyone.
Address = 192.168.50.2/24
DNS = 8.8.8.8, 1.1.1.1

[Peer]
PublicKey = Copy vpn server /etc/wireguard/public.key to here
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = VPN_SERVER_IP:443
PersistentKeepalive = 5

Once the connection is established, the AllowedIPs = 0.0.0.0/0, ::/0 setting will route all IPv4 and IPv6 traffic through your VPN server, changing your Mac's public IP to your server's IP.

If you only want a private network without changing your public IP, set AllowedIPs to your VPN subnet (e.g. 192.168.50.0/24) and restart the WireGuard client.

Make sure you have added your Mac client's public key to your VPN server config at /etc/wireguard/name0.conf:

## Client 1
[Peer]
PublicKey = Paste your mac client's public key here.
AllowedIPs = 192.168.50.2/32

Then restart the VPN server:

sudo systemctl restart wg-quick@name0

That's it — enjoy your self-hosted, free, and open-source VPN!

How to Auto-Unlock LUKS2 Encrypted Disks at Boot with Clevis and Tang

Fatih Şennik — Tue, 12 May 2026 12:21:45 +0000

Originally published at fatihsennik.com

The Problem

Full disk encryption is great — until you reboot a headless server at 3am and realize you need to type a passphrase with no keyboard attached. Every reboot now requires manual passphrase entry. That's... not great when your server is a headless VM sitting in a datacenter rack in another city.

Enter Clevis and Tang. Together they let your server auto-unlock its LUKS2 volume at boot — but only when it can reach your Tang server on the network. No Tang server reachable? No unlock. It's elegant and your data is safe even if someone walks off with the physical server.

How Clevis talks to Tang (and why it's clever)

During boot, Clevis contacts Tang and initiates a JOSE/JWK key exchange. What makes this secure is what doesn't happen — your LUKS passphrase is never transmitted, Tang gains zero knowledge of the disk key, and the derived secret exists only in RAM long enough to unlock the volume. The wire traffic reveals nothing useful to an attacker and the Tang server never sees your LUKS passphrase; it just participates in the math.

Let's say that Tang server is unreachable, then Clevis gets no response, the key exchange fails, and the disk stays locked. You can still fall back to a manual passphrase, which is a separate LUKS keyslot you keep as a backup.

Keep a backup passphrase keyslot! Clevis adds its own keyslot but doesn't touch your existing passphrase. Keep it. Store it in your password manager. If Tang ever goes down permanently you'll need it. LUKS supports multiple keyslots for exactly this reason.

Installing Tang on your secure key server which is located in different location.

Tang runs as a simple systemd socket service. It's lightweight — It functions solely as a key exchange endpoint, requiring no database and no configuration files other than the key material it generates automatically. it automatically generates its key material in /var/db/tang/. That's it. No config needed.

apt-get update

apt install tang jose

# Enable and start
systemctl enable --now tangd.socket

# Change its port to any. Example: 9102
nano /lib/systemd/system/tangd.socket

systemctl daemon-reload

# Verify it's running
curl 127.0.0.1:9102/adv

Keep the server security hardened via a separated network segment and a secure random port. The /adv endpoint returns Tang's public key advertisement as JSON. If you can curl it, Clevis can reach it during boot. If you can't, neither can Clevis — fix your firewall first.

Installing Clevis on your luks encrypted server.

apt-get update

apt install clevis clevis-luks clevis-initramfs clevis-systemd

# Find your LUKS2 device
# Replace /dev/sda3 with your actual LUKS partition
cryptsetup luksDump /dev/sda3

# Check your manual passphrase before reboot!
cryptsetup --test-passphrase --key-slot 0 open /dev/sda3

# Bind your LUKS2 device to Tang key server
# it will ask for your existing LUKS passphrase
# Then will fetch Tang's public key and add a new keyslot for LUKS partition.
clevis luks bind -d /dev/sda3 tang '{"url":"http://your-tang-server-ip:9102"}'

When you run that bind command, Clevis contacts Tang, fetches its public key, generates a random key, encrypts it using Tang's key material, stores the encrypted blob in the LUKS2 token metadata, and registers it as a new keyslot. The actual decryption key never leaves your machine unencrypted.

Before embedding Clevis into your boot process, check your network interface name — it could be ens192, eth0, or something similar.

ip a | grep -E "^[0-9]+:"

⚠️ Important Gotcha: To avoid the "network isn't up yet" issue during boot, check how your server receives its IP address.

Clevis needs to reach Tang before the root filesystem mounts — but if your network interface isn't up yet, the whole thing silently fails and drops you to a passphrase prompt.

Open /etc/netplan/50-cloud-init.yaml and verify whether your server is configured for a static IP or DHCP.

Open initramfs

nano /etc/initramfs-tools/initramfs.conf

# and add this to end of the file if your server is configured for static ip
IP=SERVER_IP::SERVER_GATEWAY_IP:SERVER_SUBNET::NETWORK_INTERFACE_NAME:none

# if your server is configured for dhcp then
BOOT=network
DEVICE=NETWORK_INTERFACE_NAME (ens192)
IP=dhcp

# Update your boot process
sudo update-initramfs -u -k all

Wait before rebooting. Test !

# Try to unlock manually using Clevis 
clevis luks unlock -d /dev/sda3 
# Check if Tang server is reachable
curl http://your-tang-server:9102/adv

And that's all there is to it. Your disk will now decrypt and unlock automatically during boot, no manual intervention required.