DEV Community: Georgios Moustakas

Stop using AI as a search engine with extra steps.

Georgios Moustakas — Tue, 16 Jun 2026 20:27:40 +0000

I watched a developer spend forty minutes going back and forth with Claude on a database schema problem. Every message was a question. Every reply was an answer. At the end of forty minutes they had a schema that technically worked and felt wrong in ways they could not explain.

The problem was not the model. The problem was the format. They were using a conversation as a Q&A session when they needed a thinking session. Those are different things.

How the search engine habit forms

Google trained a generation of developers to interact with computers through queries. You have a question, you form a concise search term, you get results, you close the tab. The whole interaction is built around a question you already know how to ask.

That habit transfers badly to AI. When you treat a language model like a search engine you are constraining the interaction to questions you can already frame. You get answers, not insights. You get syntax, not architecture. You get what you asked for, which is often not what you needed.

Search engines retrieve information that already exists somewhere. That is useful when you need a fact. It is useless when you need to think through a problem that does not have a pre-existing answer.

What a reasoning engine can actually do

The difference between retrieval and reasoning is the difference between a library and a colleague. A library gives you what is already written down. A colleague can work through something new with you, push back on your assumptions, and tell you when your plan has a hole in it.

Language models can do the second thing, but only if you interact with them the right way. And the right way looks nothing like a search query.

Here is what I mean in practice. These are two different interactions with the same underlying question:

Search engine mode: "What is the best way to structure a Python microservice?"

Thinking partner mode: "I am building a Python microservice that processes webhook events from three external APIs. Each API has different retry behaviour and payload shapes. I am considering a single FastAPI app with a queue in front of it versus three separate lightweight consumers. We have two engineers who will maintain this. What are the tradeoffs I am not seeing?"

The first interaction gets you a blog post. The second gets you a conversation that makes you think harder than you would have on your own.

The context is the work

The engineers getting the most out of these tools are not the ones with the cleverest prompts. They are the ones who bring the most context before they ask anything. They describe what they are building, what constraints they are operating under, what they have already tried, and what feels wrong even if they cannot say why.

That last part matters. "This feels wrong but I cannot say why" is one of the most productive things you can put in a prompt. It gives the model permission to probe your assumptions instead of just answering your question. Nine times out of ten it will surface the thing you were sensing but could not name.

Why most AI interactions feel shallow

Shallow interactions happen when the question is too clean. Real engineering problems are messy. They have competing constraints, legacy decisions, team dynamics, and deadlines baked into them. When you strip all of that out and ask a clean question, you get a clean answer that does not account for any of it.

The mess is not noise. The mess is the actual problem. A model that does not know about the mess cannot help you with the mess.

The shift in practice

Before your next significant prompt, spend two minutes writing down: what you are trying to accomplish, what approach you are considering, and what you are uncertain about. Then give all three to the model before you ask your question.

This sounds like more work. It is more work. It is also the work you should have been doing before you started writing code. The model did not add that step - it just makes skipping it more expensive.

A search engine needs a clean query. A thinking partner needs the full picture.

Stop cleaning up the mess before you ask. The mess is the context. The context is everything.

Your AI assistant is not hallucinating. It's guessing, and you asked it to guess.

Georgios Moustakas — Tue, 16 Jun 2026 20:18:27 +0000

Andrej Karpathy said it plainly in 2023: language models do not know they are wrong. They have no internal signal that flags uncertainty. They generate the most probable continuation of whatever you gave them, and they do it with the same confidence whether the output is correct or completely fabricated.

That is not hallucination. That is how the architecture works.

The word "hallucination" implies the model drifted on its own - that it wandered into fiction unprompted. That framing lets you off the hook. The more accurate framing does not.

What is actually happening under the hood

Large language models are next-token predictors. At every step, the model produces a probability distribution over the entire vocabulary and samples from it. The output that emerges is the sequence that seemed most likely given everything before it. There is no lookup table, no database of facts it checks against. It is pattern completion operating at scale.

When the model produces something wrong, it is not because it had a moment of confusion. It is because the probability distribution it built from your prompt pointed toward that output. The wrong answer was the most likely answer given the input you provided.

This distinction matters because it changes where you look when things go wrong. If the model hallucinated, there is nothing you can do - it is a flaw in the system. If the model guessed badly because you gave it a vague prompt, that is your problem to fix and you can fix it right now.

The gap is always in the specification

The pattern that shows up most consistently: outputs that look wrong are almost always responding to inputs that were underspecified. The model gave a reasonable answer to the question that was actually asked, not the question the engineer thought they asked.

These are different questions:

"How do I connect to Postgres in Python?" - the model answers with something that works somewhere, probably not your exact setup.
"How do I connect to Postgres in Python using psycopg3, connection pool of 10, on Ubuntu 24.04, behind a Cloudflare Tunnel, with a 30-second timeout?" - now it has actual constraints to work with.

The first prompt has six implied decisions the model has to guess. The second prompt has none.

The difficulty of writing a specific prompt is the difficulty of knowing what you actually need. If you cannot write the specific prompt, you do not yet know what you need. That is useful information - it means you should stop prompting and start thinking.

The confidence problem

What makes this genuinely tricky is that LLMs produce wrong outputs with the same fluency and confidence as correct ones. The prose sounds authoritative. The code looks clean. There is no stutter, no hedge, no signal that says "I am filling in a gap here."

This is where experience matters. A junior engineer reads the output and trusts it because it looks right. A senior engineer reads the output and asks: where did I leave room for interpretation? Every ambiguous word in the prompt is a decision the model made without you. Every missing constraint is a place where probability took over.

The second-order problem: retrying without changing anything

When an output is wrong, the most common response is to resubmit with a slightly different wording and hope for a different result. Sometimes that works. More often it does not, because the problem was not the phrasing - it was the missing context.

Retrying without fixing the specification is the AI equivalent of restarting a service without checking the logs. You might get lucky. You have not fixed anything.

What to actually do

When an AI output is wrong, read your prompt before you rewrite it. Ask where you left room for interpretation. Add the missing constraints. Be specific about inputs, outputs, error handling, dependencies, and edge cases before you ask for the implementation.

A useful habit: before submitting a prompt, reread it as if you were a new engineer joining the project with no context. What would you have to guess? Everything you would have to guess is a place the model will guess too.

The model is not lying to you. It is showing you the shape of what you did not specify. Once you see it that way, the fix is always the same.

Write tighter prompts.

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!!