DEV Community: Georgios Moustakas

The networking problem behind every "random" backend outage.

Georgios Moustakas — Sat, 13 Jun 2026 13:21:07 +0000

You get paged at 2am. The service is down. You check the app — no deploys, no config changes, nothing. You restart the container and it comes back. You go to sleep. It happens again Thursday.

It was never the app.

I spent three years doing satellite internet support before I moved into backend engineering. That job taught me one thing: most "application" problems are network problems wearing a disguise. I see the same patterns now in backend systems that I saw then in rural broadband infrastructure.

Here are the ones that get teams every time.

The timeout that isn't a timeout

Your service calls a third-party API. It times out. You log it, you retry, life goes on. But the retries pile up. Each retry holds a connection open. Your connection pool fills. New requests start queuing. The queue backs up. Now your service looks down — but the third-party API recovered ten seconds ago.

The fix is not a shorter timeout. The fix is a circuit breaker. Don't retry into a wall. Detect the wall and stop knocking.

DNS TTL lying to you in production

You rotate a database host. You update the DNS record. You wait for TTL to expire — 300 seconds, fine. But your app has been running for six hours and the old IP is baked into the JVM DNS cache, or your connection pool, or a library that ignores TTL entirely.

The new host is up. The app is still talking to the old one. The old one is gone. Outage.

Always set TTL aggressively low before a planned DNS change. And test your app's actual DNS resolution behaviour, not just the record.

The packet that never comes back

TCP connections are stateful. A NAT device, a load balancer, a firewall — they all keep track of active connections. Leave a connection idle long enough and that state entry gets evicted. The next packet on that connection goes nowhere. Your app is still waiting for a response that will never arrive.

This is the silent killer of database connection pools. The DB is fine. The network path is fine. But the connection your pool thinks is open has been silently dropped by a load balancer that forgot it existed.

Keepalives exist for this reason. Use them. Set tcp_keepalive_time lower than your NAT timeout. Most default settings are wrong for production.

MTU mismatch on the path nobody checks

A packet leaves your server at 1500 bytes. Somewhere between you and the destination, a link has an MTU of 1400. The packet needs to be fragmented. If the DF (don't fragment) bit is set and ICMP is blocked — which it often is — the packet is silently dropped. The connection hangs. Nothing in your application logs explains why.

I saw this constantly in satellite networks where overhead compression changed effective MTU. I still see it in cloud environments where overlay networks, VPNs, and tunnel encapsulation all shave bytes off the path.

Run tracepath instead of traceroute. Check PMTUD. If you're running on Kubernetes with Flannel or Calico, know what your overlay MTU actually is.

The retry storm

Your upstream is slow. Your service retries. Every service instance retries at the same time because they all hit the same timeout window. Your upstream — which was recovering — now gets hit with 10x normal traffic. It goes down again.

Add jitter to your retries. Exponential backoff without jitter is a coordinated attack on your own infrastructure.

Why this matters more now

More surface area means more network paths. Microservices, managed databases, external APIs, LLM providers — each hop is a place for the network to betray you. The app is often the last thing to blame.

When something breaks randomly and the restart fixes it, start at the network. Check connection pool state, check DNS, check keepalive settings. The answer is usually there.

The app was fine the whole time.

Stop vibe coding. Start using AI with intent.

Georgios Moustakas — Sat, 13 Jun 2026 11:27:01 +0000

Everyone is vibe coding. Prompting an AI, accepting whatever comes out, shipping it. It works until it doesn't, and when it doesn't, nobody knows why.

I use Claude Code every day. Across planning, implementation, and review. But the way I use it looks nothing like what gets posted on Twitter.

The vibe coding trap

Vibe coding assumes the model knows what you want. It doesn't. It knows what you typed. If you type vague things, you get vague code that passes a surface-level read and breaks on the third edge case.

The output is only as good as the intent behind the prompt. That's not a model problem. That's a thinking problem.

I have watched engineers prompt their way into a working demo in 20 minutes and spend two days debugging production because the model made a reasonable-looking decision that was wrong for their specific data shape. The model was not wrong in any general sense. It was wrong for that context, and nobody checked.

What "with intent" actually means

Before I write a single prompt, I know three things:

What this piece of code is supposed to do
What it must not do
How I will verify it works

That sounds obvious. Most people skip steps two and three entirely.

Step two is where security holes live. It is where the off-by-one errors live. It is where "handle the error case" gets interpreted as "swallow the exception and return None." The model will do something reasonable. Reasonable is not always correct.

Step three is where you find out if you actually understood the problem before you started prompting.

Where I hand it the wheel and where I don't

I use Claude Code to move fast on the parts where speed is the point: boilerplate, repetitive transforms, first drafts of tests, scaffolding a new route that follows an existing pattern. These are low-risk, high-repetition tasks. The model is faster than I am and the output is easy to verify.

I slow down and take over on the parts where judgment matters: data modeling, failure modes, anything that touches auth or external APIs, anything where "plausible" and "correct" are different things.

The model is a force multiplier. Force multipliers amplify what you bring. If you bring nothing, you get nothing, faster.

The review step nobody does

After Claude Code writes something, I read it. Not skim it. Read it line by line. I treat it like code from a junior engineer who is very confident and occasionally wrong in ways that are hard to spot.

I evaluate AI models professionally at Datawise. We run structured benchmarks across dozens of tasks. One thing I have learned from that work: these models are very good at producing output that looks right. Looking right and being right are not the same thing. The gap between them is where bugs live.

Reading the output is not optional. It is the job.

The prompting discipline that actually matters

Vague prompt: "write a function that processes user input"

Specific prompt: "write a Python function that validates and sanitizes a username: ASCII only, 3 to 30 characters, no spaces, raise ValueError with a clear message on failure, no dependencies outside the standard library"

The second prompt gets you something you can ship. The first gets you something you have to rewrite.

The more specific your prompt, the less reviewing you have to do. That is the actual skill. Not knowing which AI tool to use. Not having the right subscription. Writing prompts that leave no room for interpretation.

The actual workflow

Plan in plain language first. Write out what you want and what you do not want before you open Claude Code. Let it draft. Read what comes back. Push back on anything clever. Verify against the original intent. Ship.

That's it. No magic. Just using a powerful tool with the same discipline you'd bring to any other part of the stack.

Vibe coding is a fine way to prototype. It is a bad way to build things that need to keep working.

LLM API Tokens burning your Bank even on testing ? Not anymore, cuesheet is here to help with that.

Georgios Moustakas — Wed, 27 May 2026 08:01:26 +0000

Tests that called #Claude in CI were quietly burning tokens and breaking on every other run.

So I built cuesheet.

One decorator around your test. The first run hits the real API and saves the response to a YAML file you commit to your repo. Every run
after that replays from the file. Byte-identical, no network, no cost.

It works with any Python SDK that sits on httpx, which is most of them in 2026. #Anthropic, #OpenAI, #Google Gemini, #Mistral AI, #DeepSeek AI, and more, Together.

The pytest plugin auto-discovers cassettes in tests/cassettes/. Streaming responses get recorded as raw SSE chunks and replayed in order. API keys, JWTs, and emails are scrubbed before write so cassettes are safe to commit.

There is a local web UI too. Dark + ochre, watches the filesystem, refreshes live as your tests record new conversations. Useful for code review and for the "what did the model actually say" moment.

v0.2.0 is out today.

GitHub: https://github.com/gmoustakas/cuesheet
Project Details: https://www.georgemou.gr/projects/cuesheet

Open source, MIT. If you have been writing LLM tests and quietly hating it, this might give you a few hours back.

🚀 Why Every Developer Should Think Like a Product Builder (Not Just a Coder)

Georgios Moustakas — Thu, 21 Aug 2025 19:36:19 +0000

Software development isn’t just about writing lines of code. It’s about solving real problems, making things that people actually use, and shaping the web in ways that impact millions. Too often, we focus only on frameworks, languages, and tools—but forget the bigger picture: we’re builders.

The Trap: Chasing Tech Trends

Every week, Twitter (sorry, X) lights up with debates:

“Is React dead?”
“Is Rust the new C++?”
“Will AI replace developers?”

Chasing every new technology can feel like running on a treadmill—you’re moving fast but going nowhere.

The Shift: From Coder to Creator

The best developers I’ve worked with didn’t just know syntax—they thought like product people. They asked:

Who is this feature for?
Does this design make sense?
Is this solving the actual problem?

This mindset shift transforms your work from “just code” into something meaningful.

Web Development Today: Building With Superpowers

We’re living in a golden age of web development. With tools like Next.js, Vite, and TailwindCSS, spinning up a slick, production-ready app is faster than ever.

But with great tools comes a responsibility: don’t just build cool stuff—build useful stuff.

The Human Side of Development

At the end of the day, code is for people. Whether it’s an e-commerce checkout flow or a developer CLI, real users will interact with what you create. Thinking about their experience is what separates a “good developer” from a “great one.”

Final Thoughts

Being a developer isn’t about being a “code monkey.” It’s about being a problem solver, a builder, a creator. If you approach every project with the mindset of “how will this actually help someone?”—you’ll not only stand out as a developer, you’ll make work that matters.

✍️ If you liked this article, follow me for more thoughts on web development, software, and building products that matter.

Update on my PDF file manipulation Script

Georgios Moustakas — Mon, 24 Feb 2020 13:43:58 +0000

Hi again, in my previous post i had a problem on how to search a large PDF file for a keyword which can be found in multiple pages of the file and in some cases more than once in single page!

I've used PyPDF2 to open a given PDF file, then extract the text page by page, search that text for the given keyword and then check in what page the keyword was found and how many times per page and finally split those pages from the original file and merge them all together to create my final file so it can be printed with the useful data and not with other non-useful data from the original file.

All works fine with test/dummy data in English Characters but the original file is in Greek and the

PdfPageObj.extractText()

function of PyPDF2 returns an empty string.

So how would you approach this problem?
Any Suggestions?

PDF file manipulation with python 3 (Problem)

Georgios Moustakas — Sun, 23 Feb 2020 10:16:19 +0000

Hi, I have a problem I would like help with, i'm working on a project/script with python 3 where I want to manipulate a large PDF file (50-60 plus pages long) where I would like to find a specific keyword in that file, this keyword is repeated multiple times in the file and each time this keyword is referring to a different data set, then save how many times the keyword was found, in what pages was found and then split those pages from the original file and then merge those pages together in a single file.

I will use multithreading of course, because this script will run alongside other's in a small in-house server and it's already running quite a lot, other scripts.

I found some things online but no luck in what my problem is, except some python libraries that is possible to do what i'm looking for, but i have no idea how i will found this keyword in the file, because the keyword isn't in the same page order in the files, it's different in every file!!