Macro Mayhem

Welcome to another episode of Macro Mayhem. My name is Peter

Ullrich. Today is Tuesday the 18th of August. We record at 11:38

local time in Amsterdam. And with me, I have my good friend Gus Workman.

How are you doing today, Gus? Oh, I'm excellent. Coming back from vacation

this week and got a lot of energy, so that's been good. How are

you, Peter? I'm good. I come back from a sickness,

so a different story last week, but yeah,

I'm feeling slightly better. But did you see the eclipse?

I did. It was, um, a great experience.

It was also unexpected because I didn't have the eclipse glasses.

Yeah, but I was with someone who had them, so I gotta,

gotta check it out. Smart. Yeah, it's always good for the— because I also

couldn't find any glasses, so I had to rely on others. But yeah, it was

good. All right, first of all, we got a couple follow-ups from last

week. First one, right? So we got a couple comments on

audio, um, particularly my audio was very quiet. We hope

that we've made some changes that make this better.

If it's better, let us know, reach out to us, give us a shout out.

But, um, if it's not, we also— let us know so

that we can do better. Yeah, probably get a mic upgrade, but yeah, we'll see.

Yeah, and I uploaded actually another version to our podcast

app, so if, uh, with slightly better audio. So if you couldn't listen to

last week's or 2 weeks ago because you didn't hear Gus,

if you want to re-listen to it now, you can, and you might be able

to hear him actually. So hopefully. Yeah, hopefully.

So the other item is I got approached by quite a few people

about doing interviews on this podcast, which I appreciate, and thank you

for reaching out. However, right now we don't do interviews. At least we're not planning

on doing interviews. This podcast is more meant for news and blog

articles and then short discussions, but not

that much hour-long interviews. So thank you for reaching

out, but again, no interviews. And if you have something to share,

just send me a blog post, for example, or a YouTube talk,

like a talk that's on YouTube, and we can feature it on the feed.

What are we? We are a podcast. Yes. We're a podcast. So we can feature

it on this podcast, which is called Macro Mayhem.

That's the one. And it doesn't have to be your blog

post. I mean, of course you can send us your blog posts, but we're also

interested in what everyone else is reading. And if there's something that you thought was

interesting, send it to us. Exactly. Yes, please. We might make it on the show.

Exactly. All right. Uh, first news item. There were 2 really,

really interesting blog posts by Praia Labs.

They were about the Phoenix version and Bandit adoption.

And these 2 blog posts, the author looked at the

download numbers of Phoenix and Bandit,

of the libraries on HACS, and then kind of made really nice graphs

about the adoption. And what we can see there a little bit is

that Phoenix 1.7 eventually got upgraded

to 1.8, and you can really see in the graphs the adoption curve.

There's still a couple of projects running 1.6

and 1.5 out there. And even some 1.7. And all

of those are by now, I think they have major CVEs.

So if it's important, these projects,

please upgrade. And then the second blog post was

about the Bandit adoption versus Cowboy. And that

was really interesting for me as well because we are now slightly

more than 2 years, maybe 2 and a half years after Bandit was released and

the adoption has reached 50% of projects. So There's

still a way to go. And if you haven't upgraded to Bandit yet, I think

it's a good option to do that soon. And the difference

between those 2, Peter, Cowboy is Erlang,

right? And Bandit was rewriting the plug spec

interface in Elixir, right? Exactly. So Bandit is Elixir-based

HTTP web server, and Cowboy is Erlang-based.

Cool. Next up, we have Sobelow,

the security audit tool that you can run in

your— as a mixed task in your project,

had a new version, version 0.15.

This one brings a whole host of changes. The changelog is pretty

big, so go take a look at it. We will link it in the description.

But a couple of big things are it has— some good speed improvements and

some nice dev experience improvements. So thanks

to Tyler Young for tagging us on this one and highlighting some of those changes.

There's, um, Sobolo skip comments. So if you have

a known non-issue that keeps getting flagged by Sobolo,

you can inline those comments and skip them.

And again, the performance has improved. So, uh,

Sobolo is a great tool. Should be using it in your projects for

security scanning, anything that's critical. Um, even things that aren't critical,

it's good for catching LLM mistakes. So take

a look at it. Good. And next up— oh,

you, you say what's next? All right, what's next?

Next up, we have friends of the show Alex Koutmos, Hugo Barana,

and Dr. Dmitri Kutmos have released

their— it's the final version, right, of Financial Elixir?

It's not the final version. It's the first version. It's their

first released version. Yes. Right. So it's

financialexir.dev. The book title is Elixir for Finance.

They have a lot of experience in

economics and financial world. I think Dr.

Dimitris Koupmos is an economics professor.

Alex and Hugo are prolific book writers

and contributors to the Elixir ecosystem.

So this is a really— it's a good resource if you're interested in

finance, Elixir, using LiveBook for visualizations,

using graphing, different types of financial graphs.

It's, yeah, it's a good resource for the community. And it's

good to see that there's still more books being published in the age of AI.

Exactly. So this is, I think, this is the 3rd book of Alex and Hugo.

They first released Elixir Patterns, and then now Programming Nerds

in Elixir. And now I know that Alex, he teamed up with his brother,

Dimitrios Koutmos, and yeah, they wrote Elixir for Finance.

So it mostly uses LiveBook and

Explorer and these kinds of libraries to do data science. Ish on

financial data. So if you're interested in financial analysis

and you want to use Elixir, this book is for you.

Next, I wanted to pitch a little small library that I saw on Elixir

Forum, which I quite enjoyed. It's called ll-amex,

and it's a Credo plugin to clean up Ash-related LLM-isms.

And I quite like it because I use Ash in my latest

project, and I do see that LLMs do certain

things that are not quite conventional, and they like to do them

a lot. For example, just to create a new query inside a

query in like an Ash filter.

Well, don't quote me on the exact key terms here, but if you have like

a filter in Ash, and then inside that filter query, they might create another

query, which is, you shouldn't be doing that. You should have a separate

filter that you can use. So these kind of LLM-isms

this Credo plugin flags, and then you can just tell your LLM, fix them and

don't do that again. And that one was Ash-specific

though, right? There's other ones? So this one is Ash-specific,

but there are also 2 other ones that I like to use a lot.

One of them is from Jump. It's called Credo Checks. Also, I think it's Tyler

Young who mostly maintains this, and they're really nice to

catch stuff that, you know, Credo doesn't catch by itself. And then they're a

little bit, opinionated Credo checks. So you can just enable

what you like and disable what you don't. But the Jump Credo checks are really

useful. And then another one is called ex-slop.

It's, again, a Credo plugin you can add to your Credo checks.

And that also kind of catches some of the LLM-isms generally

in Elixir and Phoenix. So I personally run all 3 plus

Credo, and that helps me a lot with keeping the code quality up

or higher generally.

Now, the next item is something— it's a YouTube video. It's not

necessarily Elixir or Beam related, but I thought it was so interesting that

I wanted to mention it. And it's the Black Hat USA '26

OpenAI Hugging Face incident video by 2

researchers from OpenAI. And they walk through the entire timeline of

the OpenAI Hugging Face incident. Where an OpenAI model not

only hacked Hugging Face, they also hacked the entire OpenAI infrastructure

twice. It's quite funny when you listen

to that video and they're like, yeah, so, you know, the model

escaped and they basically took over the entire internal infrastructure,

but we fixed it and then we released it. And yeah, well, 2 weeks later,

the model did the same again. It also hacked Hugging Face

and you're like, Maybe you should be learning from your mistakes, but okay.

But yeah, this was a very funny slash interesting video. And I thought,

you know, if you are just interested in what happened with all the OpenAI,

Matter, Anthropic, and even

the ASAI hacks, you know,

watch this 30-minute video and it gives you a great overview of what

has been happening there with these hacks by models escaping containment.

Last up, sorry that I do 3 in a row, but the last one is

also a tip from myself.

This was recommended to me by my good friend Marcel

Fahle, who's working on Bolt Video. And it is also,

again, not Elixir related. Sorry, this week is a little light on the Elixir news.

But this library of skills, of LLM skills,

I found so absolutely useful that I wanted to mention it.

And it's called Impeccable. And these are

a bunch of skills designed by a designer to help

your LLM create better designs, UI designs, UX designs.

And I've been using it again on my latest project. And it's absolutely stunning on

which design issues the LLM finds and corrects.

So I run everything, I do all my UI designs through Impeccable now.

So, you know, if you are doing web app, UI design,

if you have to create that, use the Impeccable skill set to

improve it. Nice. That's a good tip. I'll have

to check that one out. Next up, last up for the

news, a kind of follow-up on last week.

Last, what was that, 2 weeks ago? We're not consistent yet.

Last episode. Last episode is that Dockploy,

the deployment solution that we were discussing, had version 0.30

released, which had a bunch of nice-to-haves,

including they now support secrets

management through external secrets providers. So before that, some of

the environment variables were— and secrets were just stored as environment

variables and not in a dedicated secret environment.

So that's an interesting one. There was a little bit of discussion on on using

that. And maybe we'll revisit this at some point as we— as

members of the community go ahead and upgrade and use it.

So— Dockploy. Yeah. We had that discussion about Coolify versus

Dockploy. And this is your choice.

Yeah. That was my choice. Good. Working on you.

We're going to convert you. Maybe. Let's see. All right.

Next section, blog posts. Yep. So, a couple

of cool blog posts this past couple weeks.

One, first one we want to highlight is Andrea Leopardi, one of

the Elixir core team members,

shared a blog post on genstage demand visualized.

So, it was an interactive blog post because there was a bunch of little widgets

inside that helped you visualize how Genstage works

under the hood. Now, if you don't know what Genstage is, it is one

of the— it's not in

the Elixir core library, standard library, but it

is one of the, like, core— one of the things the core team works on.

And it's a job processing, queue processing system

with backpressure. And so For

some, it is maybe not super intuitive how all that

works, but this blog post does a great job of breaking it down,

showing how in Elixir we have concurrency, we can have concurrent processing

of these jobs or events, and how it kind

of keeps the system in check without overloading things using backpressure.

So that was a really cool blog post. Go check it out.

Yeah. The coolest thing about this was that Andrea,

he added a lot of visualizations where you can play around with parameters and

they really show you nicely how the back pressure sometimes doesn't work

when it's misconfigured and, you know, why it's useful. So it's not just text,

it's also really cool graphs. Yeah. And I also got to

say huge kudos to Andrea for making this because the first

time I opened this link, I was on mobile and it still looks stunning.

So that's amazing. That's not easy. Maybe he used

Impeccable, who knows? Who knows? Yeah. All right. Next blog

post is by Arjun Gilliat. Uh, he is

a recruiter actually in the Elixir and Beam space,

and he gave a lightning talk at the ElixirConf EU in '26

in Malaga, where he's talking about the Elixir hiring paradox.

And he also wrote a blog post about his experience at ElixirConf and particularly

about the hiring paradox, as he calls it.

And in the lightning talk and in the blog, he covers the 3 mistakes

that he sees that companies make when they hire for Elixir developers,

and Beam developers, I assume, in general.

And the 3 mistakes, I'm just going to spoil them for you, because then,

you know, you can go off and read the rest of the blog post.

The first mistake that he sees companies making is that they don't give the

candidates a clear overview of what is expected from them

in the first 90 days. So, how does success look to the company

in the first 90 days. And that is important for the candidate as well

to understand, what am I getting into? What is, you know, asked of

me? Do they want me to ramp up super fast and start

contributing? Or do they want me to first take my time and understand the architecture

and the codebase, that kind of stuff? Yeah, so the first 90 days also

gives a good overview to the candidate of how the job will

look like once they're hired. So yeah, Arjun,

he didn't see a lot of companies do that, so he pointed it out.

The second one is that companies mistake volume of applicants

for momentum, which is, yeah, you get 1,000 applications

on your job position and you think, oh,

we're doing a good job, but actually you're

not. You should filter out with your requirements already. If you get thousands

of applicants, So applications doesn't mean that these are individual applicants.

You just didn't filter well enough. Maybe you just said,

oh, I'm looking for a backend developer, and then you have PHP people

coming to you, although you need an Elixir developer. That's an obvious mistake, but these

kind of things. So he's saying, no, you should filter, you should have

better filtering criteria.

And if they're too weak, you get too many applications.

And then the last part is also, especially for Elixir,

ecosystem, where Arjun says,

screening for years in the stack rather than reasoning.

So when you do a candidate interview, you might do a whiteboard

exercise where you ask them, can you write me a LiveView with a handle_event and

whatnot? So you kind of test them for the syntax of the language

and different libraries. But honestly, if you're, you know,

if you're especially interviewing senior candidates, they might

just walk away. I would walk away if you would put me in a whiteboard

exercise, because I'm like, first of all, who writes code these days anymore?

You know, that's now also a thing of the past, maybe.

Second of all, like, are you looking for a junior developer?

Because just writing a LiveView, like me proving to you that I know how to

write a LiveView out of my head, which I by now would also not know

too well, maybe I could do some stuff, but I would definitely trip somewhere.

But, you know, why aren't they talking about senior stuff like architecture, software design,

you know, understanding the pros and cons of different approaches to,

you know, handling demand? You know, maybe we should use GenStage, as Andreas says,

like these kind of questions, like, why do we even bother with

doing whiteboard exercises instead of talking about

the senior stuff? So, Arjun, he says, you should rather look

at Elixir thinking, which also includes, you know, when should

you use a GenServer? When shouldn't you use a GenServer? These kind of specifics

about using Elixir instead of another language. So you should rather

test for that instead of just asking, do you know the syntax of a LiveView?

That kind of stuff. So I found it was a quite interesting blog

post from a different perspective, from a recruiter's perspective.

And also one other thing I didn't know, that the number of

Elixir developers that have shipped significant products

in the European Union is in the low thousands. So,

you know, 2,000, 3,000 developers

in Europe, which is not a lot if you think about it. You know,

this is really like— PHP is like, what, hundreds of thousands?

Java, even more. And we're .NET.

Yeah, like, you know, we are a few thousands. And yeah,

exclusive club, kind of exclusive. But the point here in the blog post

is if you screwed up Word goes around, word gets

around. And that is true. I heard that also from others who interviewed for

a company that they just didn't like. The interview was like, the process was terrible.

And I also didn't apply to them then, you know, and word gets around.

So you— and you're talking about the, if you screw

up, the you in that statement is the company. Yes. If companies

have a terrible hiring process, that gets around. Yes.

But also for candidates, I gotta say. So You know,

if you just really appear to be a bad candidate and

you make it public, yeah, you might have an issue with finding another job

because even companies talk. Yeah. All right. Enough about that.

Cool. Let's move on to Tidewave. There's an update

to Tidewave, which is a paid tool.

There's a free version adding an MQTT server.

It's free. You have like 20 prompts. But it's €10,

$10 a month. So it's basically free.

Well, there's a couple parts to it. I know there's the free MCP and then

there's the Tidewayve tool. And the Tidewayve tool got some

updates that are pretty nice. So there's a Tidewayve

toolbar, which is a minimal toolbar that sits inside

your app. So you don't have to load the whole Tidewayve UI with

the chat bar on the side. You have this small toolbar and it

is more limited in functionality. It gives you a couple

of features that allow you to click and ask for UI variants,

analyze accessibility, some diagnostic stuff.

But it's a nice way to minimally integrate Tidewave with your development

process. And then Tidewave Connect, which as I understand

is an MCP kind of similar to the

Claude in Chrome or Playwright MCP, where it

allows Tidewave to then drive the browser and

interact with your web page and test everything, make sure things are working as

it expects. So if you're a Tidewave user or you've never tried it

and want to give it a try, this is a cool update. And yeah,

nix-deps.update tidewave.

Exactly. I think with Tidewave Connect, the, the issue they're solving here is

that previously, you could only connect your LLM to the browser

or to the website in the browser if you would use

the Tightwave UI. So you couldn't see your full website and it's

an iframe inside the Tightwave UI. This is

how I use it all the time. But yeah, the issue sometimes is you just

want to have your full website in front of you without an iframe

and something. And if you run your LLM in a

terminal session, separate from your browser, you could not connect that

session to the browser and let it drive the browser,

do browser eval. You couldn't click on certain elements

and say, hey, change the color of this element. So Tightwave Connect

and the toolbar, they kind of make it so that you can run your terminal

in your session in a terminal somewhere, and it can connect to

your browser through the Tightwave Connect MCP. And then you can use the

Tightwave toolbar to kind of click on certain elements and tell your LLM,

hey, you know, change these HTML elements.

So, right. And this was a blog post. So there's more details

in the blog post. And plenty of YouTube videos. Yeah. So, oh yeah,

they're very good about making those. It's very helpful.

It's, they're really good at marketing, aren't they? Yeah.

So the next blog article is by Mike Zonick.

Yeah, he also has been writing quite a bit in the last couple of weeks,

which I appreciate a lot. Thank you, Mike. And he wrote a skill

for updating your dependencies. And I found this extremely

useful because in these days where someone, someone who

we shall not name, is finding a lot of vulnerabilities

in popular libraries. And if these vulnerabilities then

get announced, you know, you either have to upgrade to the

latest version or you have to live with the warnings in your

terminal and then maybe you're crashing CI/CD. Forever. And the issue here is

when you upgrade a dependency, you previously

would have to go manually into the changelog, understand what the changes are,

what the breaking changes are, that kind of stuff. And it takes

time. So Mike, he wrote a skill, an agent

skill that does all of that for you. It looks at the changelog,

it tries to understand what needs to be changed in your

application. And then it proposes these changes.

So, you know, you can always go and double-check.

But at least this, you know, gives you a jump ahead of upgrading

to the latest version and making sure that, you know, the breaking change

doesn't affect you because you made sure that, yeah, it's not breaking

for you, basically.

Yeah. Right. Next up,

we have a blog post by João Paulo

Abreu. I think I got your name right, but I'm

sorry if I didn't. Learning Elixir: Alias, Import,

Require, and Use. So, this was a nice overview on more

of a beginner blog post on what are the differences between some of the keywords

in Elixir, the alias, import, require, and use, and how

you can use them differently to achieve

the goals of of your code.

So, using different modules, essentially. I— for

longtime Elixir developers, these are very familiar. You use them

in most modules. But it's a really good

overview of— also, it goes into some of the deeper details

of what happens with a couple of gotchas when you can alias and

you can change the alias name using the as keyword, what happens

when you have conflicting imports,

things like that. And so, it's a good read,

especially if you're new to Elixir. And,

yeah. What I found useful here is that he goes into details

about the differences between, especially, import, require, and use.

Because, yeah, what's the difference between import and use,

right? I think, but don't quote me on this, I think quote is a compile-time

dependency. So if you change your use module, you have to recompile all

the other modules that use it. Whereas import,

I don't think you have to recompile the other modules. So read

the blog post and tell me.

We shall make it a follow-up next week. Maybe we need

a session on macros because those are the Elixir magic, huh? I think there's

a whole book written about it, Macro Programming.

Probably. There is, there is, I think. Yeah.

All right. Uh, second to last item in the blog section. Uh,

it's a blog post, again, not related to Elixir. Sorry about

that, but it's, I thought, really interesting for 2 reasons. It's called

How AI Text Watermarking Works, and it's written by dClaude,

which I think is a product for, you know, rewriting Claude's

text output. Again, not that interested in the product, but the blog post was very

interesting because the European Union now since

a week or two ago requires all AI-generated content

that includes images, videos, and text to be watermarked.

And surprisingly, or maybe not surprisingly, OpenAI and

Anthropic have been watermarking the text output that the

LLMs generate in a very, very interesting way,

in a statistical way. In a way that this blog

post explains, which is basically if you know the weights between,

yeah, in your model, you know, and then the model predicts the

next word in a sentence, like that next word could

be, you know, let's say 1 out of 4, and you have different probabilities for

each of these 4 words to appear next.

So if you would write

normal text as a human, you know, we don't have these mathematical probabilities

of choosing the next word. We might choose a word that we think

sounds better or correct or flows better in the text.

But an LLM, it's purely mathematical probabilities,

right? So the watermarking here is basically

checking the text that you have and

then the words that appear in the text against your weights

in the model. And because only you know the weights in your

model, it's not something that somebody else can change or imitate.

Right. But yeah, what you basically do is you count

the words that come next and then you make statistical

analysis of that and say, well, in 30% of the cases, the next word is

module or task. And then you check against your weights.

Does that match our weights. And this way they

have been basically watermarking the output text, which I found really interesting.

But again, if you want to understand this in more depth, go read

the blog post. And this was also another

good blog post, a really interesting one, because it had the interactive widget

that let you visualize and see how they do that watermarking. Exactly.

And so you can play around with that tool. That was, it was very cool.

I like the deep dive there, but it also makes me wonder,

um, I guess maybe not wonder, but it's probably a bit

of a feature for the big LLM labs that only they can tell if

it was watermarked by their model. So I guess if you as a user want

to see if something was AI text, then you'd have to dump it

into a whole bunch of different LLM providers.

Yeah, they do expose such tools now, or they want to expose these because that's

also required by the European Union that you as a model provider

provide a way to check whether something was generated with your model.

So yeah, you send your text to Anthropic and they give you like a thumbs

up or thumbs down whether it was generated by Claude, for example.

Yeah. Right. And as a user, you'd have

to send that to Claude, to Codex too.

DeepSeek to all the labs. Exactly.

But that also brings me to a little PSA, which is you should not be

using AI to generate blog posts. That is my official

and unapologetic opinion on this topic.

I don't think AI should be in any creative output,

to be honest. And I don't include code because whether code

is art or not, it very much depends. But if you think about music,

writing, image generation, you know,

that kind of stuff. And yeah, I also have generated blog posts, like blog post

images myself, just very small thumbnails. But generally, I'm not a fan of

using LLMs for generating this kind of output, this kind of content,

and especially not blog posts, right? And the thing here is because in

doing the research for this podcast, I click on links on Elixir Forum

and they take me to like a dev 2 or something blog post. And I

start reading it and I just immediately can spot that this is an AI-generated blog

post. And the second I realize it, I drop off, I don't read the

rest of the blog post. And I will also, you know, hold it against

you as an author, like me personally, but I think generally your

reputation is damaged if you just push out AI-generated blog

posts because they're just simply slop, honestly. I don't want

to read them. Nobody wants to read them. And especially if you didn't bother writing

them, why should I be bothered reading them.

And I just wanted to make this clear, like, I will also not, you know,

put any blog post here and feature them that I think were AI generated.

And I think by now you can kind of spot it. Right.

I like, there was a phrase going

around a little while back, but human attention requires human

effort. So if you didn't put the effort in to write your post, then why

should we put in the effort to read it? Exactly. So yeah, just don't

do it. I mean, I use AIs to proofread everything I write, or most of

what I write. So, you know, you can definitely use it in your flow,

but don't just say, hey Claude, write me a blog post about this topic.

You know, you won't improve your writing skills. You won't understand as well

what you're writing about and you will, it will hurt

your reputation. It just doesn't give you anything. Like,

just don't do it. Yeah. All right, enough ranting.

Now, Gus, are you ready to do a speedrun,

1 minute or less? Yes. Through all the meetups

and conferences coming up in the next 2 to 3 months.

I'm gonna time you. All righty. Start your timer. Ready, set,

go. Go. All righty. Meetups and conferences.

We have ElixirConf US on September 9th for

workshops and 10th and 11th for the conference. Prior to that, also on September

9th, if you're not going to the workshop, check out the Unconference organized by the

Erlang Ecosystem Foundation. They always have a great time at

the Unconference. We talked about them last time, our experience at the last

Unconference. Go check it out. GOTOmire, AshConf,

and Hackathon. The whole week of Elixir Fest

happening in Varberg, Sweden is happening on September 30th

to October 2nd/3rd for

the, the AshConf and hackathon. So check out goatmeier.com

and AshConf. There's a Luma that we will link in the description.

And the hackathon also at the same time as AshConf, you can kind

of mix and match between those throughout the day if you like, also in the

description. There is Code Bean EU, which is on October

20th for workshops and October 21st,

22nd for the actual conference. Again,

Erlang Ecosystem Foundation is organizing an unconference before

that on October 20th. There's a Luma in the description that

you can go check out and codebeameurope.com for the conference.

Both of those are going to be great events. All of those are going to

be great events. Conferences, workshops,

meetups, they're the great way to interact with the community. Go check them out.

How did I do? Very good. I think that has been 1

minute. I didn't, I didn't time the seconds, but it's been

less than 2 minutes. So very good. Cool. All right.

Well, that was some hard work, Peter. I missed this

last week, but you're again known for delivering dad jokes

at the beginning of all your blog posts. So do you have a dad joke

for us? I do, just to lighten the mood a little bit, to decompress.

So, um, I don't usually brag about my finances,

But my bank calls me every day to tell me my balance is outstanding.

Very good. A good chuckle.

That's what I'm going for. That's a good one. You got a chuckle. Good chuckle.

You got a chuckle. All right. Now we're decompressed

and relaxed. We go into the second part of this podcast,

which is the discussion section. Again, if you're not interested in listening

to us ramble on about topics,

feel free to come back next episode. And thank you for listening. But if

you're interested, what are we talking about this week, Peter? We're going

to talk about something that has been on my mind

for a while now. And I think on many people's minds,

which is, how will we as especially senior developers

work in 2 years' time from now, or, you know,

going forward with LLMs now doing most

of our job? You know, like, that's my question. So because

there are 2 things here. First of all, I want to say this first,

you know, if you code on hobby projects in your free

time, non-professionally, you know, there's absolutely

no necessity to use LLMs if you don't want to. If you want to be

the artisanal and write code by hand and understand something in depth,

be my guest. There's no pressure at all. It's kind of like just

taking your time to paint a beautiful painting in your backyard instead of printing

something out with OpenAI or generating something with OpenAI, right?

So that is not what I

want to talk about. In your free time, do whatever feels best to you.

But when it comes to the professional experience, to us professional developers,

I think the trend is pretty strong that in

a year or 2 or 3, if you don't know how to use LLMs,

or if you don't use LLMs in your workflow, you might not be employable

anymore. That is, I think, a hard fact that we

can't ignore. I think LLMs and AI in general

is here to stay. I don't think there is a big financial

bubble that's going to pop and then everything's going to just

go away. There might be a bubble that will pop and there will be companies

who have negative consequences in maybe a recession.

That might happen, but it's not going to take away this technology because

it has been proven so useful and it's so ubiquitous by now.

So my personal grief or my personal

struggle with this is very much, what does it mean for me in

2 years' time? How will my job, my daily work look like? Would I

just be prompting LLMs all the time or not? You know, and if,

and then let's say I am just doing everything through LLMs,

which honestly I'm already doing today. Like I haven't written a single

line of code in 6 months, maybe manually.

So it's not because, you know, I,

I'm super on the scale of I want to use LLMs for everything. It's more

like I find them super useful. I'm more of a product person than a person

who enjoys writing code by hand.

I rather want to build stuff. I'm a builder, right? So anyway,

my big question, what's struggling,

what's my struggle a little bit is asking, how will

I as an engineer also keep on developing if

the LLM writes everything for me,

right? How will I understand the

architecture, the codebase? Will I understand the codebase or not?

You know, and how can I, if I have to use LLMs, how can

I still make sure that I understand the codebase going forward? You know,

so these are a lot of questions that roam my mind. And that's what I

wanted to bring into this discussion. I don't have any answers for it yet.

I just have some tangents, some ideas,

but no answers. And just to base the discussion

on some other content, other stuff

that we have found in the last week or two, there have been 2

very interesting blog posts, one of them by Brett,

brettcoates.com. He wrote, I'm Done Using AI.

And I found this blog post extremely interesting.

Because it goes through his experience of first going

all in on LLMs after, you know, like 15,

20 years of being a developer and then just doing everything through LLMs,

kind of burning out with it. And then going back to writing

everything by hand because he understood that he

doesn't develop as much anymore as an engineer. Like he gets

stuff done, but he doesn't learn from doing these kinds of things.

That was his first struggle. And the second one is also that he doesn't feel

as connected with the product he's building,

you know, if an LLM builds it for him. So these

2 things, and then he decided for himself, I'm just gonna go back to writing

everything by hand. And then also ending with,

I know that for him, it means or might mean that he

won't be employable in a year or 2 from now. Because, you know,

the trend just goes towards employers wanting

people who know how to use LLMs. So that blog post made

me think a little bit. And then there was one that you mentioned,

Gus, by Groen. Right, by Niklas Groen.

It was more of a— I like the title and I like

the message, but the

body was a bit more about how you shouldn't, um, how you shouldn't

just copy-paste LLM responses. But the title was Don't Be a Meat Proxy.

And I think that's a good way of, of, um,

also conveying how it kind of feels like we're living in this day and

age, is that if you're just the one that

refreshes the page, confirms the changes, and the

LLM is doing all the work, are you just a meat proxy?

Is that all it is? And so I think it

kind of goes into that arc as well about how, where does

LLM fit in your workflow? Where do you fit in

your workflow? Exactly. Yeah. And his point here was,

you know, don't just copy paste the answer that Claude gave

you into, you know, like an issue on GitHub or like a pull request on

GitHub, especially when the author comes to you and asks, your question,

can you explain this to me? And then you just take the question, put it

into Claude, and copy the output and put it back into the— don't do that.

That is just bad for everyone. I feel this myself when

I'm working with NeRFs and hardware, is that this

really resonates because I feel like sometimes I have a

throwaway project I don't really care about, and I'm not really paying that

close attention to what Claude is doing, but all of a sudden it prompts

me and says, hey, can you plug the board in? I can't access it right

now. I really feel like I need proxy then. Yeah,

but, uh, so it's interesting because I think what

you're also talking about here is that,

is that you don't go through the process of learning and discovery.

You might learn about the answers, and again, I'm going to relate this

back to NURBS a little bit here, is that I feel like LLMs have

exposed me to a lot more,

um, techniques and maybe also more understanding

of how embedded Linux works, and again in

the NURBS context. But I, I don't feel like at the same time I

have the same understanding of how the

process of determining issues like debug

debugging embedded Linux works, because Claude is very good at

generating all of those commands to say, oh hey,

this bit wasn't set in the driver, and so now the whole thing's not

working. You just need to patch this one line of code. I was like,

oh great, I understand what's not working, I understand the issue,

but I did not get the understanding of how

we got there. So I've been trying to be more intentional about about how

I use it and being in that loop and learning these tools.

Yeah. What were your techniques there? Because it's the

same issue here, right? Like you, you have your NURBS device or hardware and

you tell Claude, build me this. And it goes off and builds it and

you test it and it works, you know, and you might review the code or

not, but in the end you haven't done the whole thinking process,

you know? So Do you have any, like,

takeaways from how to understand your, uh, how to improve your understanding of it?

Well, I think so. And this comes from the embedded

Linux side. So maybe not all of this is applicable, but being

not just in the loop, but not, not letting there

be a loop is part of it. I think you can definitely use

LLMs to discover, uh, things and techniques. I think

it is very hard to search for information. About best

techniques, especially with specific situations when you have error messages and things like that for

debugging embedded Linux. The tools all exist. They've been around for the last 25

years. But the discovery, what is the name of that

tool called? What is— if some of them you type like

Valgrind --help and it spits out the giant list of

all the arguments because there's a bajillion of them that have been added over the

last 25 years. And then you get a little overwhelmed and say, well, now am

I using this one? Am I using that one? But no, you can also take

that and dump that output into an LLM to figure out exactly how you

need to use that tool to debug the issue that you're doing. But as long

as you're typing the commands, it's kind of like writing. When you're— when I was

a student, I always wrote my notes by hand because that helped me remember it

better. But in this case, instead of copy pasting, typing out the commands myself,

going through the process myself, not letting Claude be

the one that's driving the session, the debugging,

whatever. That really helps. Then you're learning what's

happening. And I think the same applies to Elixir. Yeah, that's,

that was my next question because, um, like, that's interesting that

you, you know, you'll want to learn a CLI that you can use to debug

stuff and you want to understand how to use the CLI to debug stuff and

which arguments to use, right? That's interesting. But the

learning of it is kind of like a small part of it where you now

know that there is such a CLI and you know which arguments to set

to look at certain things you want to debug. Right. But then,

for example, when it comes to the code of writing your NURBS application,

like, do you need to know how to, you know, write all

these functions in a single module when you know what the module will do?

So, you know, where do you Where do you draw the line? Where do you

draw the line? Yeah. Yeah. That is, that is more

interesting because again, I'm comfortable with writing a

gen server. I'm comfortable with writing a LiveView. I am

more results-oriented in that sense. But as you

said earlier, it's about the architecture. It's more about the understanding

of your application, your codebase, your your—

how the entire thing works together, right? And so,

I think, I mean, even then,

understanding dependencies, like, maybe instead of the

whole debugging embedded Linux example, you could say, learning how to

improve your compile times and using— understanding how to use

mix xref and getting the graph of your compile time dependencies.

That's an example of tools in the Elixir ecosystem that that you would

benefit from. And then you go back and that kind of helps you understand

how all your modules are linked together

from a compile sense. And then you can decide

how to extract them.

I think I really like your last statement,

which is that there shouldn't be a loop. Like, or at least, I mean,

if there's a loop, that it always ends with you to make

and then to give the next impetus for the next loop.

Right. I think that might be a very interesting thing because I've also experienced that

now myself where I'm like, yeah, if you

take, for example, compile time, right? If you want to improve the compile time of

your application, you might just tell Claude or Codex, go off

and improve the compile time and come back when it's 50% faster, you know?

And then afterwards you review the code and you try to understand some stuff and

then you might ask questions about it. And actually, just as a side note,

There is a skill. I don't know what the name of it is, but if

you Google for it, you might find it. There's a skill that teaches

the LLM to ask you questions about the PR. So it's

kind of like a test where— Isn't that the Grill Me skill? Grill Me.

Yeah, it's called Grill Me. So it's like you tell Claude,

ask me questions about the PR to make sure I understand the PR.

So that is maybe a good— if you're at the end already and you

have the PR ready and you realize, I don't understand what the heck's going on

here. Use GrillMe and then just until

you understand it. That's one aspect. But then getting there,

I think that's a really interesting part there that you said, which is that

you're always the driver and the LLM executes on your behalf,

but then it comes back to you and asks like, okay, so what's next,

basically? But another

part here is also you are intentional

about slowing down the process, right? Because if

you wanted to go for maximum velocity, you would just, this is my problem,

Codex, go off and fix it and come back when it's fixed,

right? And then you might review it a little bit, and then you could

maybe understand the design choice or

the architectural choice it made. You could criticize some code conventions,

use Credo checks or yourself go in and say, I don't want to use

these kind of things. Add that to your agent's MD file.

But I think if, yeah, I think the major thing here is the

intention of slowing it down so that

you are always in control and understanding what's happening. And then you can

still have the LLM write the actual code. You know what I mentioned earlier,

you can still have it write the module, but then come back to you

and say, I'm done. What's next? You know?

Right. Or on the flip side, I think that LLMs

are, and our unnamed friend,

uh, of all people certainly knows this, are great at reviewing code,

identifying potential issues. And I think also writing the tests to

confirm those issues and then confirm that they've been fixed

once you have been flagged of them and kind of determine

what to, how to, how to proceed. That is what I use

it the most for, which is code review, and Claude

has a /code-review, but I improved it a little bit because that

one also just gives you a list of issues that

you don't understand as a human. If you paste it back into

Codex, it might understand it. But the issues I had with it is

that I, first of all, don't understand the issues it flagged. So I wrote

my own skill based on it that says, give me always kind of like a

one-paragraph explanation of what the issue is. What the impact

might be and what potential solutions could be. And the

other thing is that if you just do this code review in a loop

and you have, you know, like I have Codex write the code and then Claude

review it, and then that's the loop that I do 10 times until Claude

doesn't spit out any bugs anymore. But sometimes

there are decisions that I should be making so that

Codex doesn't flip-flop from one side of a problem to the other side and

then back again, you know? So sometimes it doesn't check something and then it checks

it too much and like, That's what I've experienced in 10 review

cycles. It went from A to B and back 5 times.

So then I told in this skill, it's like, whenever there's a bug

that does this flip-flop that goes from one extreme to the other,

when it happens more than 2 times, or when it happens 2 times,

flag that to me and let me make the decision,

and then record the decision and give it back to Codex to

implement. And that, again, this is a bit more of a hand— this

is the code review part of the process. But even here, you can

put yourself back into the loop, you know, and you always have to

nowadays prompt the LLM and say, give me enough context for me to understand

the issue, right? Again, it's intention.

Yeah. Right. Well, let me ask

you this and kind of move our discussion forward is how much

do you enjoy that process? A lot.

I got to say, I'm very happy with this because again,

I am more of a product person. I'm more of a builder and I am

more of a software design and architecture person. You know,

I love designing how the system works

on a high level architecturally and then also inside the

code in one application like software design. You know, where do I put a cache

in front of some stuff where I don't put a cache?

Gen servers, especially active schemas.

I like to drill down on those to make sure that we don't

have too many fields or duplicate fields or too many

schemas, too few schemas, that kind of stuff. So the database model is important to

me. But yeah, again, that means I'm more of

a high-level person and I just want to have things work and be done and

be ideally bug-free. And then for everything that comes after, I also

have Sentry or AppSignal that send me,

you know, that track exceptions and tell me, hey, there was a bug, for example.

So that's why I'm less of a, I need to write every single line of

code myself, because building web applications,

honestly, like 98% of that code is just boilerplate code,

and you don't want to write it yourself, you know?

So Anyway, one last part I

wanted to mention here, and I think that's important, even if you disagree with

us in this discussion, if you want to kind of have affirmation that

you're not alone, there is a very nice project

by the Syntax FM podcast, and they had a questionnaire

that they sent out, and 1,500 developers have answered

so far, and you can also answer it. It's still open, and it's

anonymous, and they ask developers questions like, how much genuine enjoyment

or flow do you get from coding now compared to before

you started using AI heavily? As a former

psychology research student, I also got to tell you, this question is not

super optimal, but it gets the point across.

But yeah, so how much genuine enjoyment do you now get compared

to before? And 54% of the respondents said that they have

now less or somewhat less enjoyment,

which I found striking. That is, yeah, 1 in

2 people say now they enjoy working less with

LLMs than before. Only 26%,

so 1 in 4, said more or somewhat more.

So still 1/4 of people have more enjoyment

now. Another question, I think this

one's the most striking one, is, do you feel your actual coding skills are

sharpening, holding steady, or diminishing? You know,

now that you're using AI. 60% of people said

their coding skills are diminishing or somewhat diminishing.

60%. Only 13% said

they're sharpening or somewhat sharpening. Right. So that is striking.

Like 1 in 8, maybe 1 in 9 said,

I'm actually improving. However, again, you know, as a former psychology research student,

I also mentioned this to them. What are coding skills? Right.

Because for me, coding skills is literally writing code, like,

you know, the lines of code. But, and I personally, yeah,

that is atrophying. That is a skill that's atrophying, literally my fingers,

you know, my fingers atrophying. But what I'm learning, what I'm

gaining is better understanding of software design architecture.

I can focus on the bigger picture, right? So that's why this question,

I think, could have been split into 2. Like, do you understand your product more

or your software more? Or do you have that kind of stuff?

The last 2 aspects of this questionnaire were, another question

was, how often do you feel you should be producing more because

AI makes it possible? Even when you don't want to?

This is kind of this FOMO, like how much FOMO do you have now

that everyone is going at light speed and building products left and right?

65% said often or even daily they feel pressured

or they feel like they have to produce more. Again, that's the FOMO.

18% said never or rarely. So that's also a small amount that people

who kind of held steady and said, I don't need to be more productive

now. I might do the same job or more on my same job,

but not more than 8 hours a day. I'm not going to do 12 and

14 hours. And lastly, and I think this is the core

point of the whole questionnaire that we can discuss, is there was the strongest

correlation between answers on these questions was between

coding enjoyment and perceived coding skill change.

And this was particularly striking in people who said that

they enjoy coding less, way less.

And they also perceive that their coding skills are atrophying

or diminishing. And these kinds of things, they went

together. So, you know, correlation, causation,

like we can't say which causes what, but If

you are feeling that your coding skills are diminishing, you will also have

less enjoyment. Or if you enjoy coding less, you might

also put, oh, I'm also atrophying in my skills here, right?

Yeah. So what I found striking about this questionnaire is that it's very much,

well, it's not black and white. It's not like everyone

hates it and loses their skills, right? There are also like 1

in 4 people who enjoy it more. But, you know, the picture

is that it definitely isn't skewed towards the, yeah, I'm learning

more, I'm being more productive, I'm super happy. More people are unhappy than

are happy about this. So, Gus, first impressions,

what are your thoughts? I think, I mean,

I think it's understandable. Now, you and I, we both kind

of work in more of an independent situation, but I think if

I was in a corporate environment, at this stage,

I think I would also feel more

pressure. I would feel like it's— I mean,

this is also very dependent on what your corporate culture

is like, but I think I would feel more pressure to be productive while

at the same time feeling like I'm coding less. I think

those kind of go hand in hand, and I probably wouldn't be too happy about

it because I would feel my coding skills are atrophying.

So, yeah, I completely get it.

I think you and I are probably, again, similar in

that regard that we're more of the results-oriented.

And I mean, we want to be invested and involved in

the process, but we don't want to be writing the JavaScript. I mean, that's why

we do LiveView, right? So For us,

I think there is more intrinsic

enjoyment out of the process, even if LLMs

have their problems and, you know, there's things that you don't like about them.

But, um, it does feel in

a way that you're able to speed up the

parts that you may not enjoy as much, like writing the

tests, doing the reviews. Things like that.

I don't know. Yeah, I agree with you. I think also the independent versus

employment situation is important. Like, I am also a contractor,

you're a contractor, so we're a bit more free on choosing,

you know, what we work on, how much we work on it, and then

how we work on it. Like, what, which tools do we use?

Yeah, I think if I was, again, if you're employed and you don't

quite enjoy the work, now you have AI to just take care of for you.

But yeah, I think just to wrap up this discussion,

because we're also getting close to the 1-hour mark. For me personally,

my takeaway now is, because the initial question was like,

how are we going to work in 2 years' time as senior developers?

I think again, LLMs are here to stay. So we kind of need to make

friends with them and see how they are useful to us.

I think it's a realistic risk that

our skills might atrophy or diminish, that we're

either plateauing or diminishing in our professional

expertise, especially in the long term when you

don't then understand the projects you worked on,

the solutions you found to technical problems, and you

can't explain that in the next job interview basically. Right?

Right. So I think Yeah, that is a realistic risk.

So how can we mitigate it? I think what you said was really interesting,

which is put yourself back into the loop, make yourself

the driver, not the co-driver, the passenger.

Eliminate the loop. Yeah, eliminate the loop. There's no

loop, but there's like a request-response kind of thing where

you send something off and then it comes back to you and says, okay,

what's next? And also planning,

I agree with you, you can plan ahead.

Have a plan, but you are executing, you're the driver on the plan.

Yeah. And I think this will help you to still be more efficient

because you don't write the code, but you still get the gains

of understanding what's happening and why.

But I also think an important part is here for you personally to

decide where do you draw the line? Do you want to

understand every single line of code? Do you want to understand everything on a

module level? Do you want to understand it on an even higher level than that?

Again, I think it's for you, what feels best for you and what's

most important for your job. If you're an architect, you wouldn't go into lines of

code anyway. You would understand applications and the large

system. Yeah. And I

think to be intentional, that is the most important part, to be intentional

about your use of AI. And understand the downsides and

the benefits that it can give you. Yeah. Is that— do

you share this or? Well, I share that, but I think I would also add

the— I think that this is a— of

course, it's a time of disruption that we're seeing across the industry,

across a lot of industries. And that can feel

scary. It can feel You

can have a lot of feelings about it. And I think what ultimately

comes down to is that we shouldn't just

be talking to the machines. The communities that have built open source software

are the most valuable

resource in our industry, I would say. And the human-to-human connections

that we've made from those interactions, from those communities,

from the conferences, from the meetups, from interacting face to

face, even if the face is on a screen, interacting face

to face when that's in person, or even just over the PRs.

I think that is really where there is a

lot of sense of value and that we should try to still encourage that

while also limiting the LLM from those spaces,

right? Like, like, um, everyone knows that

LLM pull requests are a major burden on, on maintainers

right now. And I think in these community projects,

especially when it's something more fun, not like load-bearing,

to quote Claude, um, but where

there's, uh, something that brings you enjoyment,

you can be part of a community, um,

be yourself in these spaces. Don't be the meat

proxy. Um, and so join the

meetups, join the conferences, talk with other people. I think we have a

shared— um, you'll find that you'll talk

with a lot of people that share similar values and opinions on AI and are

going through similar experiences because, you know, this is disrupting everyone.

So I think my ultimate message and takeaway

is go out there and join the communities,

find the communities. It doesn't even have to be in tech, you know.

Yeah, true. Just also, you know, find something else.

If, you know, it's always fine to pick up another hobby that is

not tech related, and we don't need to make money with it. Just, you know,

pick up whatever art or theater or music,

whatever you like. But I want to say, just maybe to close this off,

make 2 other statements that I think it's also, which is

where you need to be realistic about the situation, you know, like, first of all,

I don't think you can close your eyes and just make it to, like,

wish that it goes away. I think, you know, you need to

face it and you need to find a way for you that works in this

new world. However that looks to you, that's fine. It's your

personal opinion, your preference, right?

Just, yeah, make sure that you're true to yourself and

find something. But I do think you need to face it and find

an answer for yourself. Um, and, and the, the second

aspect that I, uh, I now forgot.

Uh, what was it now? It was so important on my mind.

Yeah, maybe I will, I will follow up in,

in next week. Yeah, very good.

Well, all right, it has been a fun discussion, Peter. We will save it for

next week. We'll update you on, on what Peter's last thought was.

If he remembers it. I will remember it probably in 2 minutes from now,

and then we already hung up. But anyway, all right everyone,

well, thank you very much for listening to us ramble on.

And this has been Macro Mayhem on August 18th.

We will be back in 2 weeks' time. And again, if you have

anything you would like to— yeah, probably. If you have anything that you would like

us to feature on the podcast, always tag us or send us a message.

And, uh, yeah, thank you very much for listening and talk to you next time.