FDE Role -- Isn't it an onsite engineer who specialises in ai agents!
I am unable to understand how is a FDE role different than an onsite engineer who specializes in AI agentic systems.
Am I missing something here ?
I am unable to understand how is a FDE role different than an onsite engineer who specializes in AI agentic systems.
Am I missing something here ?
It won't be surprising if GitHub tightens rate limits at some point. They already limit heavily, but the volume coding agents are pushing now is a different shape and it's only going up.
The pushes themselves are cheap. What costs them is every push firing off Actions runs and webhooks behind it. Their availability reputation is already taking a beating from all the outages.
2014 : I was told web applications are dead, mobile apps will eat the market
2016: I was told node is dead, go lang is here
2018: I was told Java is dead, better backend languages are here
2021: I was told React is dead, better FE frameworks are here
2023: I was told google seo is dead
2024: I was told Coding is dead
2025: I was told chatgpt is dead, anthropic is the llm boss
2026: I am being told my mac is dead [it is actually dead, need to buy a new one]
Since it's the age of md files with AI tools, here's an interesting thing about them. If you're seeing an md file in the browser, it's because it got converted to HTML. GitHub and services like it run the markdown through a parser and serve you the HTML.
I write about the engineering behind real systems, mostly AI and agents and what breaks at scale in production: https://cpu-bytes.com/blogs
With how good open models have gotten, RAG can feel like overkill for a lot of problems. For smaller use cases, CAG usually does the job.
Built a simple prototype to make CAG easier to understand:
https://github.com/atish-raina/cag_proto
You may find the blog post here:
If you've been working with RAG, one thing worth understanding is the difference between parametric and non-parametric memory.
Parametric memory is frozen memory. Whatever a model absorbs during training gets baked into its weights. It's intrinsic to the model and doesn't change unless you retrain or fine-tune which is expensive.
Non-parametric memory lives outside the model: vector stores, SQL databases, document indexes, internal wikis. It is cheap to update, easy to swap, easy to keep current.
RAG is the bridge between them. It retrieves the relevant slice of your non-parametric memory and drops it into the model's context window at inference time, so the model can reason over data it was never trained on. The weights never move. Retrieval doesn't teach the model anything. It just hands it a note before it answers.
Ran into this last week setting up an agent on a small EC2 instance. Build kept OOM-killing. Disk was wide open, so before sizing up I added swap.
EC2 AMIs don't ship with swap configured. Most desktop distros do. That gap is why workloads that run fine on your laptop fall over on a small VM the second memory pressure hits.
Four lines to fix it:
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
The tradeoff is real though. Disk is way slower than RAM, so swap is great for occasional spikes and bad for sustained pressure or latency-sensitive serving. If your app is paging constantly, you're hiding a problem, not solving one. For occasional bursts on dev or staging boxes, it'll save you an instance size.
Curious if anyone runs swap long-term in prod or treats it as a stopgap.
Ran into this last week setting up an agent on a small EC2 instance. Build kept OOM-killing. Disk was wide open, so before sizing up I added swap.
EC2 AMIs don't ship with swap configured. Most desktop distros do. That gap is why workloads that run fine on your laptop fall over on a small VM the second memory pressure hits.
Four lines to fix it:
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
The tradeoff is real though. Disk is way slower than RAM, so swap is great for occasional spikes and bad for sustained pressure or latency-sensitive serving. If your app is paging constantly, you're hiding a problem, not solving one. For occasional bursts on dev or staging boxes, it'll save you an instance size.
Curious if anyone runs swap long-term in prod or treats it as a stopgap.