DEV Community: Mohammad Jawad (Kasir) Barati

Vibe Engineering -- Responsible use of LLMs

Mohammad Jawad (Kasir) Barati — Sat, 22 Aug 2026 10:31:57 +0000

I sometimes hear about vibe coding and honestly I do NOT believe you as a professional developer need to do it. The journey of using LLMs is interesting, it's useful, you pick up new skills. BUT I wish devs would not stop there and go deeper, get more pro and know what LLM is doing/writing.

I read Vibe Engineering post from Simon Willison. There he says:

I feel like vibe coding is pretty well established now as covering the fast, loose and irresponsible way of building software with AI—entirely prompt-driven, and with no attention paid to how the code actually works. This leaves us with a terminology gap: what should we call the other end of the spectrum, where seasoned professionals accelerate their work with LLMs while staying proudly and confidently accountable for the software they produce?

And I wholeheartedly agree with him. It's about being highly productive, highly effective, and impactful whilst keeping accountability for the code you build. Doing it in a bulletproof way.

tl;dr

If you're going to really exploit the capabilities of these new tools, you need to be operating at the top of your game. You're not just responsible for writing the code—you're researching approaches, deciding on high-level architecture, writing specifications, defining success criteria, designing agentic loops, planning QA, managing a growing army of weird digital interns who will absolutely cheat if you give them a chance, and spending so much time on code review.

You are responsible for what LLMs generate:

You are responsible for what LLMs generate

Happy engineering. 🚀

The Evolution of AI Coding 🐒➡️🧍

So I believe we all started from vibe coding, then start to see the short comings and became skeptical. That was when I believe most of us started to "plan, execute, and review" what LLMs write as oppose to YOLO mode where you just let LLM do whatever. But for me the key takeaway is (from the Jellyfin post):

The golden rule is this: do not just let an LLM loose on the codebase with a vague vibe prompt and then commit the results as-is. This is lazy development, will always result in a poor-quality contribution from our perspective, and we are not at all interested in such slop. Make an effort or please do not bother. And again, you are free to use LLMs to assist you, but not as the sole source of code changes.

— Ref.

In short it is your job and my job to deliver code that we are accountable for.

The Vibe Engineering Mindset

✅ Automated testing: write and make sure to write tests who are valuable and serve as a spec for your code.
✅ Planning in advance: make sure to write a plan.md always and review it first. There you can break a big task into smaller chunks and potentially you can finish each step separately in a fresh context window (although you might wanna read this gist about costs first).
✅ Comprehensive documentation: make sure to document what matters and do NOT let LLMs to write whatever they wanted. In my experience they tend to go rogue and just write a ton o stuff. Make sure to look at my AGENTS.md.
✅ Good version control: in Claude they just create snapshots (essentially they are just git stashes) before making changes after receiving a prompt. We can do it too, e.g. when you wanna diverge and make a drastic change you can stash your changes and then refactor.
✅ Code review: make the LLM review its own work. Usually you might wanna ask a different LLM to do the code review. So you are getting a second opinion.
✅ A weird form of management: getting good results feels like managing a human collaborator, but with quirks.
✅ Manual QA: don't rely only on automation entirely. Test things yourself before asking QA team to take over.
✅ Strong research skills: when you hit a wall, step back and try a different approach. Try to start fresh, it really sometimes can help. You cn see a prime example of this here.
✅ Instinct for what to keep an eye on, when we have:
- A pretty standard frontend we can delegate freely. The LLM will build it, you give feedback, it improves.
- But Backend is different beast. LLMs often struggle, make bad design decisions, violate DRY principle, use tools that are not the best options out there.
- Also writing sensible tests sometimes prove to be difficult for LLMs.

Estimating Tickets/Features

In software 1.0 we had most of the times a got feeling & some criteria as to how to estimate how much effort goes into developing it. But now we have LLMs which can generate 5000 lines of code in minutes until you hit a road blocker such as LLMs going rogue, a complicated/complex feature is not working due to some tiny decision LLM made (in short it is a logical issue).

So do NOT get caught up in the hype about 10x productivity boost.

Switched to VCS Instead of the Crappy UI of DEV.to

Mohammad Jawad (Kasir) Barati — Sat, 22 Aug 2026 08:39:38 +0000

How this Started?

I initially wrote a post on DEV.to a couple of days ago (2026.08.17). Then today (2026.08.21) I edited it. But then DEV.to jumbled it up.

Solution

I asked Deepseek about what I can do, it suggested to using Wordpress, or Ghost. But when I asked it that even those platforms are 3rd part solutions and I might end up seeing the same thing. So I asked it how can I utilize git and VCS instead. Then it said to me about gitops for blogging approach. Then when I googled it I found this post: https://dev.to/kanywst/hello-world-managing-devto-articles-with-gitops-5594

So kudos to kanywst.

You can see how the repo looked like when I started it here:

Stop Copy-Pasting Parts in Docker Compose

Mohammad Jawad (Kasir) Barati — Thu, 20 Aug 2026 03:46:23 +0000

Imagine you have a complex microservice. For local development, you need it connected to a message queue, a telemetry collector, and a database. But for your E2E testing, you need a slightly modified version (different env vars, an extra mock dependency, maybe a different port).

Most engineers solve this by maintaining two massive, almost-identical YAML files. It is a nightmare to sync changes.

Or they simply do this:

$ docker compose -f compose.yml -f e2e-compose.yml up --build -d

I do NOT like neither of them. Instead use YAML Anchors (&), Merge Keys (<<:), and Compose Profiles to create a single, DRY (Don't Repeat Yourself) configuration file.

# ------------------------------------------------------------
# 1. REUSABLE BUILDING BLOCKS (Anchors)
# ------------------------------------------------------------
x-backend-depends-on: &backend-depends-on
  message-queue:
    condition: service_healthy
  telemetry-collector:
    condition: service_started

x-backend-config: &backend-config
  build: .
  user: "1000:1000"
  ports:
    - "3000:$PORT"
  env_file:
    - .env
  healthcheck:
    test: ["CMD", "curl", "-f", "http://localhost:${PORT:-3000}/health"]
    interval: 5s
    timeout: 5s
    retries: 12
    start_period: 10s
  depends_on: *app-depends-on

# ------------------------------------------------------------
# 2. SERVICES
# ------------------------------------------------------------
services:
  # --- Production / Dev Service ---
  backend:
    <<: *backend-config
    profiles: ["dev"]

  # --- E2E Test Variant ---
  backend-e2e:
    <<: *app-config
    profiles: ["e2e"]   # Only starts when explicitly called
    environment:        # Override specific ENV vars for testing
      RETRY_DELAY_MS: "100"
      TIMEOUT_MS: "200"
    depends_on:
      <<: *app-depends-on            # Inherit all base dependencies
      e2e-fixture:                   # ADD an extra dependency for testing
        condition: service_healthy
  # ...

So now how this changes your workflow:

Local: docker compose --profile dev up starts only backend + services in default/dev profile.
E2E testing: docker compose --profile e2e up automatically swaps in backend-e2e, overrides timeouts/retries.

Designing Fault-Tolerant Async Architectures

Mohammad Jawad (Kasir) Barati — Fri, 14 Aug 2026 16:25:17 +0000

Building an asynchronous TTS endpoint sounds straightforward: accept some text, return the job ID, generate the audio in the background, and upload the result to a presigned URL.

The interesting part starts when you wonder what should you do:

When things fail:
- What happens if your messaging broker restarts while a worker is processing a job?
- What happens if the service restarts?
- Who should be responsible for retrying when the presigned URL expires?
About responsibilities of each service?
About retries?
Around observability topic?

This post explores one deliberately simple design for answering those questions without turning a small asynchronous service into a distributed-systems science project 😉.

tl;dr

POST /synthesize endpoint returns 202 HTTP status code.
- This means "the request has been accepted for asynchronous processing".
- This does NOT mean "this operation will definitely complete".
RabbitMQ is used as durable, persistent job state, so we won't be losing any message.
The client owns the output destination. It supplies the presigned URL; the TTS service simply uploads to it.
Instead of client asking about a job, I reversed the data flow. In other words TTS service now is sending the state of a job to the client.
The client is responsible for choosing a presigned URL with a suitable lifetime. The TTS service should measure how long TTS generation takes and whether uploads fail, so you can detect if the service is routinely taking longer than the URLs remain valid.

The Service

Let's start with a deliberately small API. The client sends:

POST /synthesize
Content-Type: application/json

{
  "text": "Hello world, this is a test of the asynchronous synthesis API.",
  "genUploadUrl": "https://your-server.example/generate-upload-url",
  "statusCallbackUrl": "https://your-server.example/synthesis-status"
}

The service immediately responds:

HTTP/1.1 202 Accepted
Content-Type: application/json

{
  "jobId": "550e8400-e29b-41d4-a716-446655440000",
}

HTTP 202 Accepted is specifically intended for requests that have been accepted for processing but whose processing has not completed yet. The important part is that 202 is intentionally non-committal.

Note

"Non-committal" does not mean that 202 is a bad or unreliable response.

It means that the HTTP response does not commit the server to a particular eventual outcome.

Server-Side Request Forgery Attack

Traffic between services could be intercepted/tampered on the way. That is exactly why you need to:

Reject loopback/private/link-local after DNS resolution: if statusCallbackUrl/genUploadUrl is attacker-influenced in any way (or even just misconfigured), you must resolve the hostname to an IP before connecting and check the actual IP isn't 127.0.0.1, 169.254.x.x, 10.x.x.x, 192.168.x.x, etc.

Checking the hostname string alone isn't enough because DNS rebinding lets a public-looking hostname resolve to an internal IP. This matters because TTS service is about to make an outbound HTTP call to a URL it didn't choose. That's the textbook SSRF setup.

Allow-list: since we can enumerate valid callback hosts ahead of time (it's a known service), just allow-list them and skip most of the DNS-resolution complexity.

Callback Authentication

This is about proving the callback is legitimate when TTS service calls whoever who is on the receiving end.

When client calls POST /synthesize, it includes a token in the Authorization header, TTS service adds it as an extra header to the message published on RabbitMQ.

So when TTS service later calls back client, it echoes that same token back. Client then checks the token matches what it issued for that job before trusting the callback payload.

Why this is simpler than PAT/token exchange?

PATs and token exchange solve a different problem: "how does Service B authenticate itself as an identity to call arbitrary APIs on Service A, with scoped permissions, revocability, audit trails tied to a principal".

That's real infrastructure for a general-purpose service-to-service trust relationship. What I need here is much narrower: client service needs to verify that a callback claiming to be about jobId=123 is actually about the job it submitted, not an attacker (or a misbehaving other tenant) spoofing a callback.

That's not identity, it's a per-job shared secret, more like a webhook signing secret than an OAuth token. This is exactly the same pattern every webhook-based system uses, and none require the receiver to know which IdP the client service uses.

System Boundaries

TTS service	Client
Accepts the TTS request	Owns the request ID
Generates the audio	Dictates the output destination
Reports success/failure	Generates the presigned URL
Tries to upload	Handles the retry logic

The benefits of this system design:

The TTS service doesn't need to know anything about the client's storage architecture.
Simpler than having an outbox/inbox pattern. Instead of saying we should NOT reprocess the same job twice we say we do NOT care. We process it anyway. But of course this is possible since we are offloading the whole logic of retry and what if we override a newer version of text with an older one to the client which does make sense to me.

Why RabbitMQ?

DLQ feature.
Easy to scale by utilizing KEDA.

Tip

In TTS service when you pick up a message from RabbitMQ to process you have to think about when to NOT retry and drop the message. So when we call the callbacks and get a:

4xx in general = client error = "this request is malformed and retrying it unchanged won't help." A 400 on our callback because the payload doesn't match client's schema, a 404 because the job was deleted on client's side, a 401/403 because the token is wrong. None of these get better by trying again in 30 seconds. Retrying them just burns our attempt budget on something that will fail identically three times.

408 (Request Timeout) and 429 (Too Many Requests) are the exceptions because they're not really about our request being wrong, they're the server saying "I couldn't process this in time" or "slow down, I'm rate-limiting you." Both are explicitly transient by design (429 typically comes with a Retry-After header for exactly this reason) worth honoring that header if present rather than always waiting our fixed 30s, since Service A is telling you exactly how long to back off.

5xx and network errors (timeouts, connection refused) are always retryable, these mean the server (or network) failed, not that our request was invalid, so retrying is the correct default behavior for all of them, no exceptions to enumerate the way there is for 4xx.

Presigned URL Expiration

A presigned URL is intentionally temporary. The client creates the URL, so the client is responsible for choosing an appropriate lifetime.

This way we have two benefits:

If our TTS service if takes too long to generate and upload the audio file we can look at the logs (OTel is crucial) and see the issue. For example it might be our service whom is too slow or maybe our code is implemented poorly.
Client gets to choose different TTL for each presigned URL based on how many words we have, load, etc. In other words we have more room to maneuver.

Observability

For an asynchronous service like this, I'd want traces and metrics around at least these phases:

request accepted
    │
    ▼
job queued
    │
    ▼
job started
    │
    ▼
TTS generation started
    │
    ▼
TTS generation finished
    │
    ▼
upload started
    │
    ▼
upload finished

And when I say I want traces and metrics I am talking about:

Queue wait time.
TTS generation duration.
Upload duration.
Total job duration.
Job failures.
Redis failures.
Upload failures.
Expired/rejected presigned URLs.

And this is where OTel really shines.

Trace-to-Log

So I wanted to have the ability to connect a log and trace. Thus I switched to Grafana stack: Tempo for traces, Loki for logs, Grafana for visualization and OTel collector for collecting and sending logs /traces to Grafana.

And man, I love the outcome:

What About Duplicate TTS Generation?

The client decides where the generated audio should go by providing the presigned URL. In short client handles where it wanted to store the final result.

So client can generate presigned URLs for the same job to upload them to the same place, effectively overriding the old results. But this is a decision that client has to make!

Tip

Overriding is fine even if you need a durable audit trail. I mean client can handle that on its own. The TTS service should NOT concern itself with that.

┌────────────────────────────┐
| more guarantees            |      ┌───────────────────────────┐
|        │                   |      | simpler system            |
|        ▼                   |      |       │                   |
| more state                 |      |       ▼                   |
| more coordination          |  VS. | occasional duplicate work |
| more complexity            |      |       │                   |
| more failure modes         |      |       ▼                   |
|        │                   |      | client-driven retry       |
|        ▼                   |      └───────────────────────────┘
| fewer duplicate operations |
└────────────────────────────┘

When This Design Stops Being Good Enough

This approach isn't universal. For example if:

Duplicate work is unacceptable:
- For example the TTS generation is expensive. Expensive can mean scenarios such as:
  - Jobs can run for hours.
  - We make external API calls.
  - It is computationally intensive.
- Or imagine your are charging customers for each TTS generation, and if we do that for no reason they will soon enough realize it.
Every accepted request must eventually complete.
Clients cannot safely retry.
The output operation has irreversible side effects.
You need exactly-once-like business semantics.

GitHub

My piper-tts-rest-api project has this architecture implemented: https://github.com/kasir-barati/piper-tts-rest-api/compare/v3.0.0...v4.0.0

Pragmatic Agentic Programmer

Mohammad Jawad (Kasir) Barati — Fri, 14 Aug 2026 01:05:41 +0000

The rise of LLMs has been explosive. Tools like Claude Code and GitHub Copilot give both seasoned devs and juniors superpowers. But there's a catch.

Two deep‑dives (one from Anthropic, one from the Jellyfin project) lay out the uncomfortable trade‑offs we all need to see and keep in mind.

tl;dr

AI is a tool, NOT a replacement.
Be able to explain the architecture and code without the LLM.
Test and iterate manually.

Anthropic Study

In a study ran by Anthropic with this setup:

52 junior developers were split into two groups.
Both had to learn an unfamiliar Python library (Trio for async programming).
One group used AI assistants; the other didn't.
After completing a coding task, everyone took a quiz on the library.

The results were striking:

The AI group had only a small productivity gain on the task itself, but a significant negative impact on learning. The tool let them skip the deep understanding that comes from struggling through the code.

That's a sobering wake-up call for anyone who leans on AI for every
line!

But I believe we can still mitigate this to some extend by prompting LLM with something like this for a ReactJS project:

Please now write me a comprehensive tutorial in Markdown that's suitable for a complete beginner in frontend coding to walk me through what you've done here. Include a summary of the technology, a high-level walkthrough, a detailed code review with code samples, and end with five suggestions for the ways the code could be improved based on a self-review.

In fact this would go nicely hand in hand with what "Jellyfin Guideline" ask devs to be able to do.

Jellyfin Guideline

The Jellyfin project (a popular open‑source media platform) recently published a policy for AI‑generated code contributions. It’s refreshingly blunt.

They start by acknowledging the rise of LLMs, but then:

We are seeing a precipitous rise in contributors using AI … as well as criticism and concern about LLMs generally.

Here's the golden rule from their policy:

Do not just let an LLM loose on the codebase with a vague vibe prompt and then commit the results as is. This is lazy development and will always result in a poor quality contribution … we are not at all interested in such slop.

Their full guidelines (paraphrased):

Rule	Why
No LLM output in communication (issues, PRs, forum posts) - except for translations	Avoids noise and extra work for other devs
PRs must be concise & focused - if it touches unrelated files, it’s rejected	Prevents shotgun‑blast changes
You must be able to explain every change without referencing the LLM	Ensures you actually understand the code
Test your code, follow formatting, and break PRs into small commits	Basic quality hygiene
Reviewers have final discretion - they don’t care if it’s AI‑generated; they care about quality	Quality over source

And the kicker:

If you can't explain what the LLM did, we are not interested in the change.

Open Question

So I believe the fair question now would be YOLO mode vs. owning the Code.

Many of us love the YOLO vibe - just let the agent go and watch the magic happen. And that's fun, and often effective. But there's an asymmetry:

It takes seconds to generate hundreds of lines of AI code.
It takes hours/days for another devs or you to review, understand, and fix that code if something goes wrong.

The Jellyfin policy is a stand against that asymmetry. It says: "Make an effort, or please do not bother".

Agentic Programming -- Principles for Successful Vibe Engineering

Mohammad Jawad (Kasir) Barati — Thu, 13 Aug 2026 22:52:10 +0000

In this post, I cover the five core principles for effective AI agentic engineering. The golden rule? Always "be the boss." From writing a concise AGENTS.md/PLAN.md/prompt to staying skeptical and managing expectations.

Also keep in mind it does NOT matter if you are senior/junior developer.

If you’ve been experimenting with AI coding assistants (Claude, Cursor, etc.), you've likely experienced both wonder and frustration 😉. For me there were times when the assistant one shot a feature in minutes, and other times when it got stuck in a loop of repeated mistakes.

Spend Time on Your `AGENTS.md`

This is your project's command center. Keep it concise and structured around:

The style of your project: define the coding style, architecture, and approach.
A short intro into the project/repo.
Project structure.
Testing strategies.
Limitations and constraints you want LLM to always keep in mind.

I have seen this example on GitHub which can give you a good sense of what you might wanna have. But keep in mind it is not Bible.

Spend Time on Your Prompt

Section	Purpose
Spec	Clearly define what needs to be built.
Success Criteria	State exactly how success will be measured.

Work Incrementally

Stay disciplined:

Start simple.
Work step-by-step.
Validate success criteria after every major change.
Create a feedback loop: Test → Fix → Iterate.
- Iterations can be adding more features, cleaning up, addressing known bugs or todos.

This way we ensure that we never progress more than a few steps beyond a known-good state.

But before going into more details I would like to first have a definition for:

Complicated/deterministic: many parts, but the relationships between them are sufficiently predictable that expertise can determine how to solve the problem.
Complex/adaptive: many interacting parts whose behavior changes in response to one another, so you cannot reliably determine the solution in advance.

You might have heard of "don't boil the ocean" idiom. Based on what I have read this is a good advice for deterministic problems but NOT for adaptive problems. And honestly I believe it is spot on with a small deviation, we will talk about this shortly.

I just like to start with a some examples of what I consider complex and what is complicated in this context:

Complex/adaptive problem to solve:
- How does this entire system behave under changing traffic, failures, retries, recovery, scaling, network availability, and the behavior of hundreds of independent robots?.
Complicated/deterministic problem to solve:
- We need idempotency because RabbitMQ may deliver an event twice.
- How do we guarantee a data isn't lost if the robot loses power during upload?
- How do we ensure event ordering in an event-driven architecture?
- How do we implement exactly-once event processing in an event-driven architecture?

So, for adaptive problems, you need to discern the overall architecture and consider what might go wrong - obviously, we can't cover or anticipate every single scenario - but you should still try to form a coherent plan that addresses the most likely issues.

Once you have that plan, you should be able to break it down into smaller, implementable steps. This is what I meant by "a small deviation". However, now that I think about it, I suppose you might be applying the same approach even to complicated/deterministic issues, since this way of thinking helps you maintain a broader perspective.

Deterministic Problems

So if I had to give you a concrete example I would say "migrating a 10 TB PostgreSQL database to a new cluster with zero data loss and less than 30 seconds of downtime." is a deterministic/complicated problem since there may be:

Thousands of tables.
Replication.
Custom extensions.
Enormous datasets.
Legacy applications.
Tricky dependencies.
Performance constraints.
Rollback requirements.

The important thing is that the problem doesn't fundamentally change its nature because I am solving it.

Here we can analyze the system, understand the dependencies, develop a procedure, test it, and execute it. There is a discoverable technical solution and for sure we can break it apart and solve it incrementally (remember, divide and conquer).

Adaptive Problems

Imagine you are developing a solution for robots to inspect industrial equipments. The pipeline would be:

Robot
  ↓
Upload inspection
  ↓
Backend
  ↓
"InspectionUploaded" event
  ↓
Message broker
  ↓
Processing service

And suppose you have 500 robots. Normally:

100 inspections/minute
        ↓
100 events/minute
        ↓
Downstream processing service keeps up

Everything is fine. Then your downstream processing service becomes temporarily slow. Perhaps its database is overloaded. So processing goes from:

100 inspections/min → 60/min

The queue starts growing. So you have:

Incoming: 100/min
Processing: 60/min

Queue growth: +40/min

It is still fine and manageable. But now something interesting happens. The downstream processing service has a timeout. When processing takes too long, it assumes failure.

So it retries. Now you aren't actually receiving 100 pieces of work per minute anymore. You're receiving:

100 new inspections
+
40 retries
+
some additional retries from previous failures

Now the service is trying to process 150-200 operations/minute. That makes the database even slower. Which causes more timeouts. Which causes more retries. Which creates even more load.

Now add the robots. This gets even more interesting. Suppose robots normally upload immediately. But a factory has terrible Wi-Fi. So robots store inspections locally and upload them when connectivity returns. At 10:00 AM, connectivity comes back.

Suddenly:

Now you might say "Every component has sensible behavior. Why is the overall system behaving terribly?".

Because the interaction between individually reasonable mechanisms can produce behavior that nobody intended.

And this will be reported as a bug ticket with a description like this:

At 10:37 AM, the system entered a state where throughput collapsed, retries exploded, queue depth increased exponentially, autoscaling oscillated between 20 and 200 instances, database resource usage spiked, and the system recovered 45 minutes later after traffic naturally decreased.

That's a complex behavior, there may not be one broken component. Instead: A → influences B → influences C → changes A.

And the overall behavior emerges from those interactions.

Don't Get Lazy -- YOLO Trap

LLM gave you a few wins and then you're overconfident in its ability. Suddenly, you ask it to YOLO a big task and come back later, hoping everything worked.

Spoiler alert, it probably won't.

Challenge your assistant, even when it sounds confident.
If the AI says it fixed a bug, ask for evidence, root cause, and test results.
Don't let your guard down, unless you want your project to derail 😉.

Manage the Frustration

There will be times when the model makes the same mistake repeatedly, despite explicit instructions. You'll want to pull your hair out.

That's normal 🥲🥹.

These moments are not signs of failure, they're signs of limitations in the model or hitting context window limitation (imagining the model is NOT compacting it for you automatically). Your role is to detect, manage, and work around them.

Anticipate chaos.
Treat frustration as a signal to reset or reframe the problem.
Keep going, this is where real growth happens.

Advise for

Junior engineers:
- This is a learning tool - not a replacement for understanding.
- Challenge the AI with questions so you can follow what's happening.
- Stay skeptical. The AI can be confidently wrong 😂.
Senior engineers:
- You can already smell BS when the AI makes it up (I imagine you are looking at what it is writing).
- Use the tool to do more, not to replace your joy of building.

Agentic Programming -- Picking a Model

Mohammad Jawad (Kasir) Barati — Thu, 13 Aug 2026 15:06:00 +0000

Honestly ever since I started using LLMs I was always thinking of how good would it be to have a practical guide to picking the right AI model.

That's what this post is all about 😁.

tl;dr

Pick intelligence over speed: choose the smartest model you can afford. Fast models save time upfront but cost you in debugging hell later.
YOLO only with frontier models.
Baby-step everything else, including critical services you wanna vibe engineer.

Note

I believe I've mentioned this a couple of times already, but just to be absolutely clear: do NOT YOLO a mission-critical service that will be deployed to production.

If you're deploying to a QA or development environment, and you're confident that even if it fails, the consequences will be limited and won't result in significant harm, loss, or damage to anything of real value, then sure, YOLO away.

Open-source Models

You must:

Supervise it: keep an eye on the diffs.
The prompt needs to be:
- Much more precise.
- Much more detailed.
- A clear specification as to what needs to be accomplished.

Also you might not be YOLOing excluding the risk factor. You might have to do more iteration. As of now I have NOT been using open-source models. But I like to know what you think.

But if you wanna use them like I do like to use them we only have to break a big semi abstract prompt into smaller manageable prompts.

💰 The Budget Question

Trying to save money with a cheaper model? Usually that ends up costing more. Why? Because you'll spend hours debugging nonsense outputs, rewriting prompts, and iterating endlessly. That time drain isn't free, and it's mentally exhausting 😑.

When LLMs Make You Want to Throw Your Laptop Out the Window

Mohammad Jawad (Kasir) Barati — Thu, 13 Aug 2026 09:56:41 +0000

You are vibe engineering. You type a perfectly reasonable prompt, and the agent responds with utter nonsense. It invents APIs that don't exist, deletes stuff it should not, fix unit tests by changing the code in way that is just pure madness 🥲.

Key Takeaway

Remember: the agent is a collaborator, not a magician. Your job is to guide it, correct it, sometimes override it, and verify it's done what it claims. That's what makes you the engineer.

Now I would walk you through 3 things you can do to get the most out of agentic programming.

Patience + Feedback Loop

Breathe. Seriously, it helps.
Give specific feedback. Tell the agent why its suggestion is wrong. For example:
- "The current database design is needlessly expensive, we have this getAllProducs API which defaults to sort by a field which you create inside an aggregation operation. So I would suggest denormalizing the data and storing it in the database since this is a data which is created once but read often."
- "Your code didn't handle the edge case where the array is empty. Please add a guard clause."
Iterate. The agent learns from your corrections. Often, after a few rounds of back‑and‑forth, it'll converge on a working solution.

🆘 Disclaimer 🆘

I have found myself that sometime I prefer to intervene and change some parts manually since fixing the issue is way faster and productive. Then I just tell the agent I had made some changes and that it should NOT revert them (at least in my experience with Copilot and OpenCode I had to tell it explicitly if I wanted to continue working on that same session/context window).

Simplify, Simplify, Simplify

This is the single most powerful trick in your arsenal. When the agent spirals into complexity, reduce the scope. Break your problem into the smallest possible piece that can work and be tested, and build from there.

Instead of "build a full Kanban board with drag‑and‑drop, authentication, and real‑time updates", start with: "create a static HTML page that shows three columns".
Once that works, add "allow moving cards between columns".
Then add persistence, then auth, then real‑time.

💡 Key Takeaway

If you can't get a tiny piece to work, it's unlikely you'll get the whole thing to work.

And as for big architectural decisions or database design you can always brain storm first with a top model, have a semi-concrete big picture in mind. Then break that big picture into SMART steps.

Delete, Restart, or Switch

Sometimes, despite your best efforts, the agent is just stuck in a rut. It keeps circling back to the same flawed approach. When that happens:

Delete everything and start fresh. I guess this is a no-brainer, a clean context window whom does NOT have the subtle biases accumulated in the previous context window can save you.

If you are in the middle of a context window, feel free to summarize and compact the previous context window into a markdown file if you believe you would be needing it.

Sometime it also is quite helpful when your first shot misses the target, just undo whatever it did. Tweak your prompt/AGENTS.md/plan and ask it again.
If that fails, switch products. ATM we have an embarrassment of riches: Cursor, GitHub Copilot, Codex, Antigravity, Claude Code, and more. Each has its own strengths and quirks. One might be better at frontend, another at backend.
Never forget: you can always fall back to writing code yourself. The agent is a tool, not a replacement for your brain 😉.

Classic Move of LLMs When you Ask them to Fix Something

It guesses what the problem is!

This shows itself even more when you have a logical issue which is not generating any error logs. So you are not able to feed it any logs and you are just asking it and explaining what the problem is.
Changes some code.
Claims victory 🫠.

I guess you do NOT need me to tell you what will usually happen next, right? The bug is still there!

The issue is that it guessed the problem, it did NOT prove the problem by reproducing it! Now it should try to fix it (and prove the code which was changed was the root cause of the issue), and finally test and demonstrates it has been fixed!

So your prompt will be something similar to this:

...please first reproduce the problem. prove, you've reproduced it. Find the root cause. Fix it. And prove you fixed it.

Agentic Programming -- Basics

Mohammad Jawad (Kasir) Barati — Thu, 13 Aug 2026 08:20:03 +0000

What is an LLM?

A Large Language Model like GPT is a statistical pattern-matching engine designed to predict what text should come after an input sequence. Think of it as autocomplete on steroids 😅.

The model:

Takes an input sequence of tokens (chunks of text, often parts of words).
Outputs probability scores for every possible next token.
Generates responses one token at a time through a process called inference.

Key Tricks in Agentic Programming

Here are the four tricks we use in agentic programming. In fact these are applicable to any agentic workflow:

Context Engineering

The output of an LLM is based entirely on its input (the "context"). Getting this right is everything.

The context gets rebuilt for each call, you remember about LLMs being stateless, right? So when you use GitHub Copilot the extension constructs and sends the context window.

Turn N: [system + tools + history (reasoning, tools called, etc) + user message]
   ↓
Turn N+1: [system + tools + updated history (reasoning, tools called, etc) + new user message]

I know I am repeating myself, but just to be sure you are getting it: the important distinction is that the model request contains the prior conversation(s) again on the next call, but the new call is not "the previous request duplicated". It is a new request assembled from the conversation state plus the new material.

When the context window gets tight (don't wait for it to be
filled to the brim) you have two options:

Summarize everything that as been done in that session and open a new empty session.
Rely on Claude or whatever you're using yo automatically start a compaction when the estimated request exceeds the context limit ( some even have a configured output/buffer allowance).

`AGENTS.md`

A Markdown file that prepares your agent with project-specific information.

Key Principles:

Natural Language: write like you're prompting an LLM.
Concise & Crisp: every word counts (precious context window space 😁).
Focus on Positives: I always have this nagging feeling that when I have too many not to dos LLMs tend to perform worse. So try to use NOT only in a selected few places.
Hierarchical: root directory for global rules, subdirectories for specific overrides.

Be assertive: direct, commanding language that leaves no room for interpretation or negotiation.
Avoid writing:

# Project Guidelines

- It would be nice if you could try to use type hints when you remember to do so.
- Maybe consider keeping the code simple if that's possible.
- Please try not to add too many comments if you don't need to".

Instead write:

# Project Guidelines

## MUST DO

- Use type hints for all function signatures.
- Keep code simple. No unnecessary abstractions.
- Add comments ONLY for complex business logic.
- Use uv for all package management.

Here you can find my AGENTS.md, if you like it feel free to use it.

Two Approaches in Agentic Programming

Which Approach is Right? But before answering that keep in mind that it is your job is to deliver code that's proven to work. You CANNOT blame the LLM. Check it works!

Fun story, I asked someone whom uses AI intensively to code about how good LLMs and top models make decisions since I had somewhat bad experience with it. Here is what he said:

I personally find the top models usually make good architecture and design choices. but not always. Perhaps 70% of the time? If you're not mentally prepared for the 30% painful miss, then it's going to be tiresome when it happens. And you might think "Why is everyone so impressed with this?".

Project	Use
Mission Critical Projects Enterprise software Large codebases Highly innovative code	Trust, but Verify
MVPs & Prototypes Building from scratch Boilerplate-heavy Risk-tolerant	Let It Go

Trust, but Verify

TODO List	Description
Micromanagement	Approve everything, frequent resets, detailed instructions
Plan → Execute	Planning mode for finer control, then execution in phases
Spec-Driven	Specify precisely, trust the system, verify at the end

Let It Go

TODO List	Description
YOLO	No approvals needed, let it run (great for hobby projects)
Ralph Loops	Wrap the entire process in bigger loops; run overnight
Multi-Agent Swarms	Specialized agents (testing, feedback, managers) working together

⚠️ Warning

There security concerns with giving LLMs control over what they are creating with YOLO mode. Honestly I do NOT think you need to worry about it ATM. But I felt like mentioning it here.

Quick Reference Card

Concept	Key Takeaway
LLM	Statistical engine predicting next tokens
Tokens	Chunks of text (words or parts of words)
Context	Everything passed to the LLM (prompt + history + tools)
Agent	LLM using tools in a loop to achieve goals
agents.md	Markdown file with project rules and standards
Compacting	Summarizing history to fit in context window
Ralph Loops	Nested loops for long-running tasks
YOLO	Zero-permission approach for trusted tasks

Learn More

How AI Models Work for Dummies

Mohammad Jawad (Kasir) Barati — Wed, 12 Aug 2026 14:27:19 +0000

AI models live two lives. First, they learn. Second, they perform.

We call these Training and Inferencing. If training is the four years of medical school, inferencing is the actual surgery. In short all that knowledge it learned is put to the test against real, messy, unseen data.

The Two Stages of an AI Model

Every AI model goes through two primary phases. Think of it as learning versus doing.

During training, a model processes millions of labeled examples. It figures out the statistical relationships between data points and encodes those relationships into model weights. Weights are the digital "neurons" that connect ideas.

During inferencing, we feed the model new data (like a user's query or a fresh email). The model uses its stored weights to make a prediction or generate an answer.

Example

Let's make this concrete with a classic use case: Spam Detection.

Training: we feed the model thousands of emails already labeled "Spam" or "Not Spam." It learns that words like "lottery," "urgent," and excessive "!!!" usually mean trouble 😁.
Inferencing: a new email arrives in your inbox. The model compares this email to the patterns it learned and spits out a probability score.

The magic of inferencing is generalization. The model can predict a spam email it has never seen before, just because it shares characteristics with past spam.

Cost

Honestly I had this vague impression of training being super duper expensive. But then I got to know as expensive as training can be, it is dwarfed by the expense of inferencing 🥲.

Training a frontier model can cost tens or even hundreds of millions of dollars. But guess what? That can become pocket change compared to the aggregate cost of serving billions of user queries over the model's lifetime.

Scale: training is a relatively infrequent, concentrated expense. Inference happens millions of times per day.
Speed: we expect answers almost instantly. That requires powerful (and power-hungry 😅) accelerators running continuously.
Complexity: LLMs have billions of parameters. A standard dense model uses essentially all of its parameters for each token it processes.
Carbon Footprint: unlike training, inference is an ongoing source of energy consumption. At sufficient scale, it can account for a substantial share of a model's lifetime energy use.

One nuance: "inference can dwarf training" is not universally true. For a model that is trained but barely used, training will obviously dominate.

💡 Tip

A token is the smallest chunk of text that an AI model actually reads or generates. It is not always whole word. For example:

"unbelievable" → generates 2 tokens when using google/gemma-7b ["un", "believable"].

"How are you?" → generates 4 tokens when using codellama/CodeLlama-7b-hf: ["How", " are", " you", "?"].

You can play with it here: https://tokenizer.model.box

Why you actually care?

Cost: most AI pricing (OpenAI, Anthropic, etc.) is billed per token (input + output). More tokens = more money spent.

Speed: inference speed is measured in tokens per second. Bigger outputs take longer.

Memory: models have a "context window" (e.g., 128k tokens). Hit that limit, and the model forgets the start of the conversation.

From Prompt Engineering to Context Engineering

Mohammad Jawad (Kasir) Barati — Tue, 11 Aug 2026 19:17:57 +0000

tl;dr

When I first started building with LLMs, I thought the game was all about crafting the perfect prompt. Find the right words, and the model will do what you want. But then I came across Context Engineering: Sessions & Memory whitepaper from Kimberly Milam and Antonio Gulli.

If you're building agentic AI systems that actually need to work in production, this shift in thinking - from prompt engineering to context engineering - might be the most important thing you learn.

Context Engineering

LLMs are fundamentally constrained. They have a fixed context window (the maximum number of tokens they can process and pay attention to at once). Everything you want the model to consider has to fit in that window:

The conversation history.
System prompts and instructions.
Tool descriptions and their results.
RAG-retrieved information.
The user's current prompt.

The more you shove in context window, the more you risk losing what's called coherence (the model's ability to generate outputs consistent with your goals).

Stuff it full of tools, instructions, and context, and you'll get less predictable, less accurate results. And that is where you start feeling frustrated 😠🥲.

So what's the alternative?

Designe and build dynamic systems that provides the right information and tools, in the right format, at the right time, to give an LLM everything it needs to accomplish a task.

Actually that is what context engineering is all about.

An AI Developer Experience engineer at Google called Philipp Schmid DeepMind popularized this in his seminal blog post The New Skill in AI is Not Prompting, It's Context Engineering.

The Context Engineering visualizes the problem beautifully, showing everything you pack into your input context:

The elements that make up your context include:

Instructions/System Prompts: which are initial settings and rules that define basic AI behavior.
User Prompts.
Short-term memory: the flow of the conversation.
Long-term memory: user preferences and knowledge from previous interactions.
RAG: retrieved external data from documents, databases, APIs.
Available tools: functions the AI can execute.
Structured output.

Most agent failures are not model failures anymore, they are context failures.

Philipp Schmid

Schmid estimates that around 80% of agent failures trace back to broken or missing context - not the model itself being inadequate.

The Experimentation Mindset

You might be asking: "Okay, so what's the process? What's the step-by-step waterfall for optimizing context?"

There isn't one. In fact if you remember I wrote about this in Prompts Matter in Agentic Workflows
. Even when you do prompt engineering you need to do experiment and measure each change.

Context engineering is fundamentally about R&D, trial and error. Here's the only reliable approach:

Metrics: define something that measures how effective your agent is toward your business objective.
Experiment: test different approaches, different tool combinations, different ways of using RAG.
Measure: compare results against your metric.
Iterate: keep what works, discard what doesn't.

BTW do NOT forget to add traceability to your agentic workflow.

Subagents: Dividing to Conquer

One of the most powerful techniques in agentic programming is using subagents, breaking your larger agentic problem into smaller, independently testable steps.

So how you should create subagents?

Context optimization: if you've got 12 tools equipped to the same model, it might start losing coherence. Group related tools into a subagent, and now your main agent only sees one tool (the subagent itself). Your context window becomes dramatically more efficient.
Reusability: Build a subagent once, test it, validate it, and reuse it across multiple agentic flows.
Independent testability: Each subagent can be evaluated on its own, making debugging and improvement much easier.

Here is the working example in n8n: https://gist.github.com/kasir-barati/66f1284f2027e53c78bba3dacac7feed

The Trade-off

Subagents reduce flexibility in exchange for reliability. You're constraining how the problem gets solved by organizing it into fixed building blocks. The main agent can't decide to call tools in a different order, it's on rails.

This is a trade-off between autonomy, flexibility and bulletproof reliability.

Subagents in n8n

In n8n, implementing subagents is straightforward using sub-workflows. A sub-workflow can be triggered by another workflow, making it a clean, elegant subagent implementation.

The Human Trap -- Anthropomorphizing

One common anti-pattern is anthropomorphizing agents. People create agents with human-like roles (Analyst, Strategist, etc.) because "that's how the org is structured."

This is backwards. Divide into subagents because it:

Gives you independently testable steps.
Improves your evals.
Fixes a specific context problem.

Not just because it sounds like human responsibilities.

The Lethal Trifecta -- The Security Vulnerability You Must Know

This is the one vulnerability unique to agentic AI, and it was popularized by the Simon Willison.

Simon coined the term "lethal trifecta", three capabilities that, when combined in a single AI agent, create a near-guaranteed path to exploitation through indirect prompt injection.

Access to private data: the agent can see sensitive information (bank accounts, sales numbers, API keys).
Ability to communicate externally: the agent can give information to someone other than you.
Exposure to untrusted content: some of the agent's input comes from sources you don't control.

Any two of these might be fine on their own. Many systems handle private data and have multiple users. Many systems communicate externally. Many systems ingest untrusted content.

But all three together? That's where the vulnerability emerges.

The untrusted content could contain instructions that deceive your LLM into exposing private data to a third party. And because LLMs are non-deterministic, you can't simply "patch" this vulnerability like you would in traditional software.

The only way to reliably prevent this attack is to cut off one of the three legs. Generally the easiest leg to remove is the ability for the LLM agent to transmit stolen data back to the attacker (AKA exfiltration vector).

A real-world example was when GitHub built an MCP server that allowed agents to read and write from both public and private repos. It ticked all three boxes.

What Makes a Strong Agentic Solution?

Category	❌ Anti-Pattern	✅ Best Practice	Why It Matters
Starting Point	Solution-Focused: "I want an agent to write emails."	Problem-Focused: "We are losing leads because follow-ups are slow. We need to reduce response time from 24h to 1h."	Ensures you build a tool that actually solves a business pain, not just a cool demo.
Agent Identity	Anthropomorphization: "Act like a senior sales manager with 20 years of experience."	Functional Role: "Act as a data processor. Extract contact info, check CRM status, and draft a follow-up."	Prevents the agent from mimicking human "personality" which leads to unpredictable or hallucinated advice.
Success Criteria	Vague Outcome: "Make the emails sound professional."	Quantifiable Metric: "Achieve a 15% reply rate on automated emails."	"Professional" is subjective; "15% reply rate" is measurable and verifiable.
Content Goal	Generation as Goal: "Generate a 10-page market strategy report."	Accuracy & Verification: "Analyze Q3 sales data, identify top 3 growth drivers, and cite specific data sources for each."	LLMs are great at sounding plausible but bad at being accurate. You must force verification.
Testing	Human Review Only: "I'll read the output and see if it looks right."	Rigorous Automated Testing: "Run 1,000 test cases. If accuracy < 95%, add a verification tool or rule."	Humans miss subtle hallucinations. Automated tests catch errors at scale before deployment.
Control	Autonomous "Thinking": "Let the agent decide the best price to offer the customer."	Tool-Based Execution: "Agent calculates price based on margin rules. Human approves any discount > 10%."	Removes the risk of the agent making expensive, unauthorized decisions based on "guesses."
Scope	Broad & Open-Ended: "An agent that handles all customer support."	Narrow & Concrete: "An agent that handles only password resets and billing status checks."	Narrow scope reduces error rates and makes it easier to prove the agent works.

MCP: The USB-C Port for AI Applications

Mohammad Jawad (Kasir) Barati — Tue, 11 Aug 2026 00:07:58 +0000

The first time I heard about MCPs I was quite flabbergasted. I was like what are they. But today thanks to n8n I know them like the back of my hand 😁.

tl;dr

MCP stands for Model Context Protocol.
The real innovation in Agentic AI isn't MCP, it's tools.

Tools are the game-changer. The ability for an LLM to decide, based on the tokens it generates, that it wants to call a function or API. MCP is simply an standard that makes sharing and reusing these tools much easier.

Use structured output as much as possible instead of simple strings returned usually by LLMs since we can work a lot easier with JSON.

If you ask me to summarize it I'd say let's imagine we wanna create a lead hunter tool. I do NOT care how it works internally, I just wanna give it a prompt like this: "I wanna sell a CO2 calculator and optimizer to south east Asian countries. Gimme 10 top major compnaies/organizations" and then get a structured response back with direct contact info as accurate as possible.

So you go to n8n and create a published workflow like:

Then you need to create a separate published workflow which exposes the new MCP server

Then you just need to add it to your agent or you can for example add it to Claude:

You can see the n8n workflows here: https://gist.github.com/kasir-barati/eb1059bbd85abf6cadd83a10c35f4cf4

Also pay close attention to have we declared what our MCP is capable of in n8n so Claude knows what it needs to send to the MCP server and what it should expect to receive in response:

Fun Fact

The builtin n8n tools are all MCP servers with accurate and neat descriptions similar to what we had done for our little MCP server. That is why LLMs know which tool they have to call!

So the full flow of our little MCP would look like this:

And the Claude part is just the client whom initiate the request, receives the response, and finally visualize it to the user.

What is MCP?

Anthropic create MCP and released in late 2024. It took off around March-April 2025 and has become a major force in the AI ecosystem.

Anthropic describes MCP as the USB-C port for AI applications (ref), a good analogy for a protocol designed to standardize how AI applications connect to external systems.

The Three-Part Architecture

MCP consists of three key components:

MCP Host: The overall environment where your agents run (e.g., Claude desktop app, an n8n workflow, or any AI application).
MCP Client: A component within the host that connects to MCP servers.
MCP Server: The actual tool provider that exposes functionality to LLMs.

Transport Mechanisms

MCP clients and servers can communicate in three ways:

stdio (Standard Input/Output): The simplest method, but only works when server runs on the same computer as the host.
SSE (Server-Sent Events): Deprecated.
Streamable HTTP: The modern replacement for SSE, supports remote connections (server can run anywhere).

Important ⚠️

n8n currently only supports Streamable HTTP and SSE, not Stdio.

Why MCP Matters

What MCP is:
- An easy way to use tools that someone else built.
- A standard for sharing tools across AI applications.
- Open source.
What MCP is NOT:
- The tools themselves (it's the glue between LLMs and tools).
- Technically innovative (it uses proven technologies).
- Guaranteed to be the final word (alternatives like Claude Skills and Code Mode are emerging).

But even then I believe knowing MCP will enable us to have an easier time adopting and moving to Code Mode or any other standard. As the old saying goes: same song, different verse.

Learning MCP gives you the "melody", so picking up Code Mode is just learning the "new verse".

DEV Community: Mohammad Jawad (Kasir) Barati

Vibe Engineering -- Responsible use of LLMs

tl;dr

The Evolution of AI Coding 🐒➡️🧍

The Vibe Engineering Mindset

Estimating Tickets/Features

Switched to VCS Instead of the Crappy UI of DEV.to

How this Started?

Solution

Stop Copy-Pasting Parts in Docker Compose

Designing Fault-Tolerant Async Architectures

tl;dr

The Service

Server-Side Request Forgery Attack

Callback Authentication

System Boundaries

Why RabbitMQ?

Presigned URL Expiration

Observability

Trace-to-Log

What About Duplicate TTS Generation?

When This Design Stops Being Good Enough

GitHub

Pragmatic Agentic Programmer

tl;dr

Anthropic Study

Jellyfin Guideline

Open Question

Agentic Programming -- Principles for Successful Vibe Engineering

Spend Time on Your AGENTS.md

Spend Time on Your Prompt

Work Incrementally

Deterministic Problems

Adaptive Problems

Don't Get Lazy -- YOLO Trap

Manage the Frustration

Advise for

Agentic Programming -- Picking a Model

tl;dr

Open-source Models

💰 The Budget Question

When LLMs Make You Want to Throw Your Laptop Out the Window

Key Takeaway

Patience + Feedback Loop

Simplify, Simplify, Simplify

Delete, Restart, or Switch

Classic Move of LLMs When you Ask them to Fix Something

Agentic Programming -- Basics

What is an LLM?

Key Tricks in Agentic Programming

Context Engineering

AGENTS.md

Two Approaches in Agentic Programming

Trust, but Verify

Let It Go

Quick Reference Card

Learn More

How AI Models Work for Dummies

The Two Stages of an AI Model

Example

Cost

From Prompt Engineering to Context Engineering

tl;dr

Context Engineering

The Experimentation Mindset

Subagents: Dividing to Conquer

The Trade-off

Subagents in n8n

The Human Trap -- Anthropomorphizing

The Lethal Trifecta -- The Security Vulnerability You Must Know

What Makes a Strong Agentic Solution?

MCP: The USB-C Port for AI Applications

tl;dr

What is MCP?

The Three-Part Architecture

Transport Mechanisms

Why MCP Matters

Reference Resources

Spend Time on Your `AGENTS.md`

`AGENTS.md`