Personally, I really enjoy programming, and for the foreseeable future I don’t see myself caving in to the desires of using it to write code. I will most certainly use it to review some pieces of code I wrote, and ask it for implementation suggestions, but I will remain in control of the code and the quality of the applications that I produce.
I read this article the day it was published: Phoenix.new - The Remote AI Runtime for Phoenix. The TLDR is that Phoenix now has an AI agent supplied by Fly.io and it understands Elixir and Phoenix more than other AI tools apparently, so is a much better choice at vibe coding Phoenix apps.
The part from the article that concerned me the most is this:
I’m already using Phoenix.new to triage phoenix-core Github issues and pick problems to solve. I close my laptop, grab a cup of coffee, and wait for a PR to arrive
Now I don’t want to dunk on Chris at all. This is not that kind of post. I appreciate everything he has built and he is one of the OSS maintainers that I absolutely respect the most. But, knowing that the core maintainers are experimenting with AI agents to actively contribute to the framework itself is very concerning for me.
A framework is part of an application’s core architecture. They should aim to be as stable and reliable as possible, because they’re foundational. If this were happening in some optional generator for a feature that might or might not be useful then I would have totally been okay with the use of AI. But in phoenix-core?
With the latest 1.8.0 release the framework now ships with AGENTS.md, and sure we can manually delete it, but it shows how opinionated the framework is in shoving features you never asked for down your throat.
Another point about how opinionated Phoenix is, is how they changed phx.gen.auth in 1.8.0. IMHO, it was great as is. Now it comes with magic links by default, with no way to opt out unless the user goes to their settings and provides a password. What???
For me the alternative is simple. Just stick with good ‘ol Rails for everything. I respect the heck out of DHH for standing his ground in this uncertain time and doubling down on his statement that Ruby is for humans. We don’t need machines writing or reading Ruby. For those of us that have worked with Ruby we know how readable and understandable it is.
I totally get how you need to copy and paste some wild functional mess from JavaScript into ChatGPT to get an understanding of what is happening and maybe to make a couple of simple changes. We don’t have that concern in Ruby. Code is executed in a predictable way and it is concise and the purpose is clear.
Rails is also still maintained by hand, DHH is still in control of everything that goes in, and he sure as hell won’t be doing it with his laptop closed and just waiting for machine trained regurgitated slop to be fed into the framework.
I have always been on the side of the Rails users shouting out about the lack of a built-in auth (to name one missing feature). Although we did get a very basic auth generator in Rails 8, what I love about it is that it doesn’t assume much. It doesn’t force features you don’t need (or want) on you.
I totally get why Rails has (and lacks) the features it does now. The Rails maintainers are extremely considerate about not wasting your time with things you will need to painstakingly delete manually after scaffolding a new application.
In conclusion, I am still very troubled by the direction Phoenix is heading. That being said, this is all my personal opinion. Take it with the lightest grain of salt. There is no perfect language or framework. Some devs might love all this AI agent crap being stuffed into the frameworks, while it is a disappointment for others.
I really wanted to use Phoenix more in my personal projects. But from here on out I will be dedicating more time to Ruby and Rails instead. I still work for a company using Elixir and Phoenix heavily, so while this isn’t goodbye, it is more of a rebalancing of where I spend my personal coding energy.
]]>It truly is one of the most resilient syndication methods that the web has ever seen. I hope that it not only continues to exist but goes though a full-blown revival.
Social media is everywhere and it is utterly exhausting. Platforms constantly fight for your attention by sending useless notifications to your phone.
No I don’t know who Karen is and I don’t care, leave me alone Facebook!
Algorithms are constantly tuned for one thing: engagement, so they can feed you more ads. There is no other way to state it, that is pretty much the goal of every social network. Even the supposedly “pure” platforms like Bluesky are working on subscriptions, which means they’ll soon need your participation too.
There’s no sincere desire to connect people. On social media, you and your content are the product.
With RSS, you’re in control.
That blog you followed for crochet patterns suddenly turns political? Just remove their feed URL - gone. No algorithm will keep throwing their “enlightened” takes into your feed.
Unlike social media, RSS doesn’t try to “optimize” or curate your feed. There’s no engagement bait or outrage amplification. Just pure, unfiltered content. The way the internet was meant to be.
Most RSS readers show you just the content:
It’s faster, cleaner, and respects your privacy.
Many RSS readers even let you control notifications and enable offline access - perfect for catching up anywhere and anytime.
This was the killer feature for me.
No more bouncing between 20 open tabs or manually checking bookmarks.
With RSS:
It’s reading on your terms.
Everyone’s cross-posting. People jump platforms, change usernames, go silent. It’s hard to keep up.
RSS fixes that. As long as someone maintains a feed, you’ll know where their content goes (even if they abandon a platform).
You never miss an update, no matter how rarely they post.
RSS is not controlled by company. Anyone can publish a feed. Anyone can subscribe.
It’s one of the last open web standards still widely in use.
You don’t need Web 3 for this. RSS has been here all along.
Stop being fed viral outrage bait.
With RSS, there is no trending tab and you consume only what you want. It’s a calmer, more enriching way to read online content. No dopamine loops required.
Even if the blogs have comment sections, RSS shows you just the content. No distractions, no off-topic rants, no comment wars.
For those of us who want to hear thoughtful voices (not arguments from random strangers) this is a blessing, not a bug.
Social media platforms thrive on noise: memes, hot takes, political rants and attention-seeking.
RSS thrives on signal. You get content from creators, thinkers, and writers you chose to follow. No likes, no trending drama, just the good stuff.
If you value your time, attention, and sanity - ditch the feed and take the control back. Go RSS.
]]>If you read my previous post, you will know that I am cautiously optimistic about this new era of AI. I do believe that the way we as developers write apps will change forever. Does that mean we won’t write ANY code ourselves? Definitely not. Does it mean our careers and the profession in general is at risk? No chance.
In fact, skilled developers will become even more sought after as the knowledge gap gets bigger. When using generative AI, non-technical users will not be able to fine-tune, defend or scale their applications to fit all the requirements that modern web apps need. That’s where we come in.
Right now if you open two different tabs using the same AI model and you provide it the same instruction, it will generate two wildly different results. Even if you give it an existing piece of code, and ask it to change something, it might restructure or modify parts that were completely irrelevant to your request.
This immediately raises a few red flags. If you are a non-technical user, blindly deploying those changes gives zero certainty that your application code still adheres to all the previous business requirements you gave the model. Sure, you could ask AI to generate tests (if you even know what they are or should test) but this is generally when you will receive the most pointless, flaky or slow running tests. Why? Because AI simply doesn’t know any better.
The main problem with AI-generated tests is that AI learns just by observing what it saw somewhere on the world wide web and using those inputs, tries to find some pattern that works most of the time. It cannot ever truly “understand” your program logic or runtime behavior, despite what the AI companies are trying to sell you.
It will mimic basic test structures (e.g. assert something == something_else) without knowing if the output is meaningful in your specific context. It is also limited to the training data, and if that data contained shallow or boilerplate tests, it will learn to reproduce those.
AI also suffers from hallucinations, often inventing support libraries or helper methods that don’t exist. Unfortunately, there’s no real way around this.
If you look at some testing frameworks like RSpec, you see that they are extremely readable and as such, LLMs can understand your requirements way better just by looking at those. TDD anyone?
Take a look at this example:
RSpec.describe "Report management", type: :request do
it "creates a Report and redirects to the Report's page" do
get "/reports/new"
expect(response).to render_template(:new)
post "/reports", params: { report: { name: 'Daily report' } }
expect(response).to redirect_to(assigns(:report))
follow_redirect!
expect(response).to render_template(:show)
expect(response.body).to include("Report was successfully created.")
end
end
This is a highly readable piece of code, and it will outlast whatever AI-generated code we use today. If your AI agents decide to rewrite everything, you have a very clear set of rules that must pass in order for your app to hit production.
This kind of consistency will be essential for any serious company navigating the AI era.
The truth is that AI is here to stay. It will become more and more integrated into our workflows.
We need to adapt and integrate it in a way that makes sense and let us extract the good parts while also filtering out the bad use-cases.
We must also be the gatekeepers of the AI code that hits production and consciously work on ensuring that it adheres to a certain level of quality that users of a paid product deserve.
This is why I am of the opinion that we will write more test specs and less app code in the future. This is similar to what we have seen in previous technological revolutions where humans were replaced with machines, but humans remained in charge of QA.
There has always been a balance between work and quality assurance. You should only give AI one of the two, while remaining in control of the other.
If AI is writing your code (including code completions), you need to be the one writing your tests. If you don’t want to write your tests, you shouldn’t be letting AI also write your application code. Simple as that.
Don’t offload both to the machines, unless you really don’t care about your product (or your users).
You can automate code, but you can’t automate care. Care is what turns code into products that users trust.
]]>If we want to stay relevant, now is the time to plan ahead and predict what the future holds.
This is not the first time that humanity has experienced a shift this large.
During the Industrial Revolution, machines replaced manual labor in factories. It massively increased productivity but also caused social upheaval. Workers were terrified that the machines would cost them their livelihoods and transform industries beyond recognition. Sounds familiar?
Widespread electrification reshaped how businesses operated and gave rise to things like 24/7 factories and modern cities. It also birthed entire new professions: electricians and electrical engineers (to name a few). Electricity became a general purpose technology that society simply cannot live without. Candle-lit family gatherings, anyone?
The invention of computers (and later personal computers) revolutionized everything from finance to publishing to communication. Other than electricity, one could argue that it was the most important invention of the millennium. It shifted us from manual processes to automation and data-driven decision-making. Without this revolution, we wouldn’t even be here discussing AI today.
The spread of the internet didn’t just transform businesses; it reshaped culture and society itself. It led to the dotcom bubble, sure - but optimism endured. Entire new industries were born, and many old ones were wiped out. Think about it: without this revolution, we wouldn’t have a single FAANG company.
Smartphones took everything - books, websites, notes, memories - and fit them into the palm of our hands. Ubiquitous access to powerful tools changed our habits on a massive scale, for better and for worse. It also brought us mobile applications which is a very recent convenience and solves our problems in ways we couldn’t even comprehend just a couple of decades ago.
TBD.
We find ourselves at the start of a new era. There’s a lot of hype. A lot of noise. Like every revolution before, there will be a lot of trial and error. History books (or websites) will only remember the wins - and the losses.
Why the history lesson? Is this Britannica? No - it’s to highlight that all of the five previous revolutions listed above had something in common: Even though some industries (and jobs) collapsed, each revolution created new opportunities. New industries. New professions. New ways to thrive.
There’s no reason to believe the AI revolution will be any different.
So that’s it then, right? Post done. We should just sit around and wait for the next wave of jobs to emerge, then go back to college to re-skill and become junior engineers again?
You could do that.
Or, you could stay ahead of the curve - keep up with the new developments (both good and bad) and find ways to profit from it. No one knows exactly how this will unfold. Maybe all the AI companies will crash in their next seed rounds, and we will call this “The AI Bubble”.
Or maybe, like every time before, new industries will rise.
It’s too early to confidently announce what the future holds, but I remain cautiously optimistic. I am already looking for ways that this all might unfold.
I love programming. It is no secret. If I could code every day until the day I die, I’d be a happy man. But the reality is clear: AI is not coming, it’s already here. And it’s getting better every day.
We can mourn the way things were (like the folks in the Industrial Revolution did) and go burn down SkyNet. Or we can build what comes next.
Programming is about to get a major version bump. If we used semantic versioning, we’d call it “Programming 2.0”. Programming 2.0 won’t just be about writing code anymore. It will be about understanding (and applying) new tools.
The next chapter is being written - Programming 2.0 is here. Let’s get to work.
]]>You might wonder what brought me to this point in the first place. The answer is pretty simple: AI. You see, for long GitHub was an okay place to host my own repos. Never really had any problem except for the occasional outage. When AI came along though things changed. Suddenly they updated their terms to allow big daddy Microsoft to teach models based on private (at first) and public repos.
First I thought nothing of it. Now things are changing though, the rate at which the models are growing and pulling in all sorts of different material without any kind of reward or even a simple attribution for the original copyright owner’s work led me to realize that getting “off the grid” is the logical next step.
If I can’t control how my code is used, then at least I should control where it lives.
I don’t personally have any repositories (yet) that are worth learning from. When I do have any in the future though, trust me that I want to be ready!
There are lots of great providers to choose from. Some I have used before, some are new. So I had to compare them each for my individual use-case. I just wanted something lightweight that lets me push my repos up and let me work in isolation. Privacy and security are the number 1 consideration, otherwise I wouldn’t even be writing this post.
After careful consideration of the pros and cons of each I decided that running plain Git would be too much for me to manage. I would still have to figure the rest of the story for my CI/CD needs, auth, etc. it is way too barebones. GitLab, is getting a bit too “enterprisey” for me personally. If I am about to get off GitHub, why replace it with another one exactly like it. Forgejo is apparently a fork of Gitea, and is run with democratic governance. I personally don’t like politics in my Git provider, so since Gitea and Forgejo is pretty much the same I decided to go with Gitea.
Nothing too fancy here. I already paid $4 per month for GitHub “Pro” just to host private repos on GitHub Pages. So dropping the same $4 (or even just a bit more) on a Digital Ocean VPS felt like a no-brainer - I can do way more with the VPS than I ever could with a GitHub subscription.
I don’t live in the US, so being able to choose a server location closer to me also brought in the bonus of lower latency. It ain’t much, but as engineers, we have that innate tendency to squeeze out every last bit of juice we can.
I decided to skip Docker for this one. I have nothing against containers, but I wanted something a bit more simple and transparent. If anything goes sideways, I can easily debug it with plain old system tools.
First, I grabbed the latest Gitea binary for Ubuntu from the official site’s releases. I went with the stable release (for obvious reasons) and dropped it in /user/local/bin:
# change the version to whatever is the latest
wget -O gitea https://dl.gitea.io/gitea/1.23.7/gitea-1.23.7-linux-amd64
chmod +x gitea
mv gitea /usr/local/bin/Next I created a dedicated git user to keep things clean and secure: (Always do this if you run things on remote servers.)
adduser \
--system \
--shell /bin/bash \
--gecos 'Git Version Control' \
--group \
--disabled-password \
--home /home/git \
gitThen I set up the directory structure that Gitea expects: (this is all straight from their docs btw):
mkdir -p /var/lib/gitea/{custom,data,log}
chown -R git:git /var/lib/gitea/
chmod -R 750 /var/lib/gitea/
mkdir /etc/gitea
chown root:git /etc/gitea
chmod 770 /etc/giteaNearly done. Let’s create a systemd service so Gitea runs a daemon:
tee /etc/systemd/system/gitea.service > /dev/null <<EOF
Description=Gitea
After=network.target
[Service]
RestartSec=2s
Type=simple
User=git
Group=git
WorkingDirectory=/var/lib/gitea/
ExecStart=/usr/local/bin/gitea web --config /etc/gitea/app.ini
Restart=always
Environment=USER=git HOME=/home/git GITEA_WORK_DIR=/var/lib/gitea
[Install]
WantedBy=multi-user.target
EOFThen it was just a matter of starting it up:
systemctl daemon-reexec
systemctl enable --now giteaOnce the service is up and running, Gitea will be listening on port 3000 by default. I navigated to my server’s IP in
the browser and walked through the web installer. It sets up SQLite, an admin user and then you are pretty much done.
PS. you have to go through the web installer for the Gitea config to be generated.
Now you can stop here if you want, but there is still more work to be done if we want the experience to be more GitHub-like.
After pointing a custom subdomain to my server’s IP, it was time to set up the reverse proxy. Gitea runs on port 3000,
but no one wants to type :3000 every time they set up a new repo. Plus this is 2025, https is a MUST!
Time to set up Nginx and a free SSL cert from Let’s Encrypt using certbot.
First we need to install the dependencies:
apt update
apt install nginx certbot python3-certbot-nginxThen, we configure Nginx. I created a basic server block pointing to Gitea on port 3000:
vi /etc/nginx/sites-available/giteaI used this config (just with my new domain instead of your.domain.com):
server {
listen 80;
server_name your.domain.com;
location / {
proxy_pass http://localhost:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}Going great so far. Next we need to link it and reload Nginx:
ln -s /etc/nginx/sites-available/gitea /etc/nginx/sites-enabled/
nginx -t
systemctl reload nginxNow comes the more interesting part. We add https with Let’s Encrypt:
certbot --nginx -d your.domain.comThis gives us our certificate with the SSL all correctly configured. It even sets up auto renewal. Certbot takes care of all the heavy lifting so we don’t have to mess with any of the config ourselves. Sweet!
Nginx is now handling the https requests and forwarding them to Gitea, which is still happily doing its thing on port 3000.
One last thing. We need to tell Gitea it is running behind a proxy. (don’t remove the other values set under server):
[server]
PROTOCOL = http
DOMAIN = your.domain.com
ROOT_URL = https://your.domain.com/
HTTP_ADDR = 127.0.0.1
HTTP_PORT = 3000
# Optional, but highly recommended if you don't want anyone to register on your service:
[service]
DISABLE_REGISTRATION = trueRestart Gitea for good measure:
systemctl restart giteaBoom! - secure, clean and no :3000 in sight. We have our self-hosted Git server with SSL and privacy. Most importantly
we no longer have the corporate overlords scraping our commits.
Thanks for following along. If you enjoyed this post, be sure to add my RSS URL at the bottom of the page to your favorite RSS syndicator to get notified when I post anything new.
(^ That’s right, there might a future post on why I prefer RSS for blogging)
]]>