What’s the message here? I read and read a lot of words but nothing clear came through. Maybe he sort of seems to be saying that Ruby is special in modern programming with LLMs? That doesn’t ring true for me - seems that languages are less special and less differentiated than ever with LLMs, which is to say that languages just tend to be less important now and that’s a good thing. Who cares about language, just build the thing.
Is he saying that Ruby is better for LLM programming? That’s hard to imagine because strong typing has to be a big help for automated programming tools and Ruby is behind all the other modern languages on typing.
Not really Ruby per se, but Extreme Programming, TDD, and all of the mid-2000s OO-hipster methodology stuff that accompanied Ruby/Rails back in the day. His thesis is that if you just adopt XP, like you're supposed to, that translates smoothly to programming with LLMs because you can have the LLMs fearlessly take incremental steps, supported by extensive testing, and directly oversee the work exactly the same way you would do pair-programming with a human junior programmer.
Someone I know who is all-in on AI—the same person who literally said you're not a real engineer if you're not using LLMs—also made a passing remark about how exhausted he was at the end of a workday talking to the clankers.
I have a feeling the job's about to get a whole lot shittier.
The thing that made our crowd apart in the work society is now vanishing, that’s sad.
I wonder how future movies will depict programmers: depressed faces getting angrier and angrier chatting with a CLI coding agent! This will not inspire future generations!
I'm finding a good balance by only relying on LLMs for the stuff that used to make me stuck because it was just boring to do, the process of reading code, reasoning about it, and designing in my head a solution is still absolutely needed; after that it's quite easy to start hammering out a solution, sometimes I'd get a bit stuck if I noticed it would need some major changes across multiple places, I can let a LLM do that for me and get back on track.
What I can't stand even though I tried quite a bit is talking to the damn clanker at length to describe step-wise what I believe needs to be done, and keep waiting, reviewing, telling it what's wrong, waiting, reviewing, I don't think I'm at a stage where I have the mental capacity to be running dozens of clankers at once doing all their changes on their own, and just reviewing later. It's absolutely exhausting and joyless, I've tried, and at the moment it's not for me.
Well when you’re coding on your own you can get into the zone and just “flow”. With an LLM you’re waiting for the result, you see it has changed things it shouldn’t have changed and while the over all result is a step in the right direction, you have to go back and fix a lot of the LLMs “corrections” which is super tedious.
I asked Claude to help me out with an issue I was having with a small renderer I was working on, it fixed the issue but also added a memory leak, the leak was easy enough to fix because I fully understood what was going on but if you’re vibe coding and don’t have the skills to debug yourself you’re going to have a bad time.
In the end I don’t like using LLMs for coding but they are good at solving isolated problems when I get stuck. I prefer it when they review my code instead of writing it for me.
I’ve tried the paid models through GitHub copilot and I just can’t find any of them actually useful for anything more than generating tests.
They can generate stuff, but generally I spend so long fixing it manually that it makes the time savings zero or negative.
Only thing I have found useful is the PR review bot. That thing is genuinely incredible at spotting tiny mistakes in massive PRs that make your eyes glaze over.
Not GP, and I don't use LLMs either, but I find software design far more fun than software engineering. Software engineering feels like I was put in a zoo with Lego pieces scattered by all the animals and I have to recreate the model in six hours.
Apologies, errant drop of water on an already cracked screen caused an early posting.
The live markdown provides a substrate that causes the tests to run when the user guide or reference document is read. We use these reference documents in place of specs in our development, they're the same information in different form (input vs output in the whole affair when treated typically) so why not just use them that way? And marrying the unit test to them provides instant verification.
During the development process, any agent (or human) accessing the spec will also receive the current state of development free (relatively... the tests need to run) of charge.
Afterwards, the tests remain, ideally green, but as an indicator anytime anyone (agentic or human) needs a refresher on whatever that feature might have been. Tucked away down at the bottom of the page somewhere, the tests stay active so that we have an on going drift/regression detector embedded in the document that describes its function. When the entire platform is based on Turing complete markdown, it helps to keep things flowing in the right direction.
Sorry, I had to get my kids off to school (there's two of them) and daddy tends to need some help on the best of days, but the abstraction is already designed for a polyglot runtime and my entire current platform is based on Ruby (she's just so pretty isn't she...) so the guts were there. I had a Ruby SDK for the graph from a week or two ago laying around so I just needed to get the fence processor and context injection wired up.
This I think proves the power of what Obie is saying. We do RSpec now and it's glorious
That shows how we can create a single node on the graph with a pair of {{include:statements}} and a bit of ${interpolation:based-pointer.math} and poke and peek tools in an MCP proxy turns a markdown file into an Rspec test runner, just by reading the file. And that same {{include:}} lets me drop that pattern anywhere I want all over the graph, which is pretty neat.
Obie's definitely on to something with this. There's a rather lot of negative emotion surrounding the changes to our profession. There's a certain lack of joy bleeding through many of the comments. Computing doesn't have to be that way, didn't used to be anyways. If you're smart about your verification process, if you're smart about optimizing the framing of your intent, this isn't a scary world we're all crashing headlong into. Remember what they're for - they're generative not thinking - and they'll serve you well.
The snake oil salesmen who turn it into a religion/cult. The ceremony that doesn't bring any advantages. The irrational adherence to this ceremony.
"Agile/XP" is a big bag of many ideas. Some of them aren't related, but they all get stuffed in that bag.
Personally, I enjoy pair programming, which is the literal experience of dealing with an (agentic) AI for the purpose of programming.
Tests (regression tests, unit tests, integration tests, ...) make development easier in that they tell you right away when you took a wrong step. You don't have to test manually anymore, so that saves you time and concentration, and you can test a lot more often.
Author argues that values long embedded in Ruby culture (testing, readability, design) are very useful for collaborating with AI, gives an example os asking Claude to follow tdd
Ruby does have the best testing tooling of any I’ve tried. But I feel like it’s half to make up for how horribly unreliable the language is. The whole thing being untyped makes it borderline impossible to know the code is correct without unit tests covering everything.
"Untyped" means, for example, you can't tell a string from a number, because they are the same type.
You mean "not statically typed". Which also applies to Javascript, PHP, Python, ... so if that critique doesn't stick to those, it's not a critique you can level at Ruby.
Typescript has almost universal adoption at companies now. PHP I can’t imagine any company choosing for new work anymore. And Python I’m not terribly familiar with but it does seem to be moving towards types.
Ruby behaves sensibly through the principle of least surprise.
But it does have extremely powerful metaprogramming capabilities which are regularly abused by those not wise enough to know that just because you could do something doesn't mean that you should.
I regularly code in a variety of languages from C / C++ through Python and Ruby through to Haskell. They all have their advantages and disadvantages. All of them are capable of abuse by the sufficiently determined. And unit tests are helpful in all of them.
It’s quite surprising when you update Rails and they have changed the arguments for some obscure function used in only one place deep in your app and you get no indication of this until the actual line of code is run and it blows up.
I’ve worked on rails apps for the last 9 years and I’d guess 80% of the bugs that show up on production would have been flagged by typescript.
Which is what the Ruby test-heavy culture is all about. I prefer types for this very reason; the compiler/checker is a complete suite of testing I don't have to write.
I’ve seen large Ruby projects with hunders of developers working on it for >10 years with almost 100% sorbet coverage. It’s just that in Ruby you have to pay (ie spend extra time) for decent degree of type safety.
What’s the message here? I read and read a lot of words but nothing clear came through. Maybe he sort of seems to be saying that Ruby is special in modern programming with LLMs? That doesn’t ring true for me - seems that languages are less special and less differentiated than ever with LLMs, which is to say that languages just tend to be less important now and that’s a good thing. Who cares about language, just build the thing.
Is he saying that Ruby is better for LLM programming? That’s hard to imagine because strong typing has to be a big help for automated programming tools and Ruby is behind all the other modern languages on typing.
Not really Ruby per se, but Extreme Programming, TDD, and all of the mid-2000s OO-hipster methodology stuff that accompanied Ruby/Rails back in the day. His thesis is that if you just adopt XP, like you're supposed to, that translates smoothly to programming with LLMs because you can have the LLMs fearlessly take incremental steps, supported by extensive testing, and directly oversee the work exactly the same way you would do pair-programming with a human junior programmer.
[dead]
This looks like babysitting a kid. If that's how CHAT/"vibe coding" looks like - no thank you. I would be frustrated all the time.
I am super efficient these days. But that's exactly what it feels like. Coding is not fun anymore and needs a lot of stress resistance now.
However doing actual manual coding starts to feel weird as well
Someone I know who is all-in on AI—the same person who literally said you're not a real engineer if you're not using LLMs—also made a passing remark about how exhausted he was at the end of a workday talking to the clankers.
I have a feeling the job's about to get a whole lot shittier.
> Coding is not fun anymore
The thing that made our crowd apart in the work society is now vanishing, that’s sad.
I wonder how future movies will depict programmers: depressed faces getting angrier and angrier chatting with a CLI coding agent! This will not inspire future generations!
Ever see the Fritz Lang’s metropolis? Like that but sitting down
I'm finding a good balance by only relying on LLMs for the stuff that used to make me stuck because it was just boring to do, the process of reading code, reasoning about it, and designing in my head a solution is still absolutely needed; after that it's quite easy to start hammering out a solution, sometimes I'd get a bit stuck if I noticed it would need some major changes across multiple places, I can let a LLM do that for me and get back on track.
What I can't stand even though I tried quite a bit is talking to the damn clanker at length to describe step-wise what I believe needs to be done, and keep waiting, reviewing, telling it what's wrong, waiting, reviewing, I don't think I'm at a stage where I have the mental capacity to be running dozens of clankers at once doing all their changes on their own, and just reviewing later. It's absolutely exhausting and joyless, I've tried, and at the moment it's not for me.
You could... not use them. The tool makes you less efficient, it is unpleasant to use... there's no upside here.
Unless part of your compensation or even your company's policy to allow to keep working there is tied to it.
And just up and changing companies is also not a realistic option for many, before people start bleating that tired, privileged trope.
What exactly isn’t fun about coding?
Well when you’re coding on your own you can get into the zone and just “flow”. With an LLM you’re waiting for the result, you see it has changed things it shouldn’t have changed and while the over all result is a step in the right direction, you have to go back and fix a lot of the LLMs “corrections” which is super tedious.
I asked Claude to help me out with an issue I was having with a small renderer I was working on, it fixed the issue but also added a memory leak, the leak was easy enough to fix because I fully understood what was going on but if you’re vibe coding and don’t have the skills to debug yourself you’re going to have a bad time.
In the end I don’t like using LLMs for coding but they are good at solving isolated problems when I get stuck. I prefer it when they review my code instead of writing it for me.
I’ve tried the paid models through GitHub copilot and I just can’t find any of them actually useful for anything more than generating tests.
They can generate stuff, but generally I spend so long fixing it manually that it makes the time savings zero or negative.
Only thing I have found useful is the PR review bot. That thing is genuinely incredible at spotting tiny mistakes in massive PRs that make your eyes glaze over.
Not GP, and I don't use LLMs either, but I find software design far more fun than software engineering. Software engineering feels like I was put in a zoo with Lego pieces scattered by all the animals and I have to recreate the model in six hours.
We do something similar with automation we're calling Looking Glass Development (there's a theme).
https://tech.lgbt/@graeme/115608630019342209
We marry the user guide or reference manual to the unit tests into a single live markdown file. Intent and verification in a single package.
The a
Apologies, errant drop of water on an already cracked screen caused an early posting.
The live markdown provides a substrate that causes the tests to run when the user guide or reference document is read. We use these reference documents in place of specs in our development, they're the same information in different form (input vs output in the whole affair when treated typically) so why not just use them that way? And marrying the unit test to them provides instant verification.
During the development process, any agent (or human) accessing the spec will also receive the current state of development free (relatively... the tests need to run) of charge.
Afterwards, the tests remain, ideally green, but as an indicator anytime anyone (agentic or human) needs a refresher on whatever that feature might have been. Tucked away down at the bottom of the page somewhere, the tests stay active so that we have an on going drift/regression detector embedded in the document that describes its function. When the entire platform is based on Turing complete markdown, it helps to keep things flowing in the right direction.
There's a larger write up (and the odd shitpost) here https://www.graemefawcett.ca/blog/little-things/ if you're interested
Sorry, I had to get my kids off to school (there's two of them) and daddy tends to need some help on the best of days, but the abstraction is already designed for a polyglot runtime and my entire current platform is based on Ruby (she's just so pretty isn't she...) so the guts were there. I had a Ruby SDK for the graph from a week or two ago laying around so I just needed to get the fence processor and context injection wired up.
This I think proves the power of what Obie is saying. We do RSpec now and it's glorious
https://tech.lgbt/@graeme/115622344011576598
That shows how we can create a single node on the graph with a pair of {{include:statements}} and a bit of ${interpolation:based-pointer.math} and poke and peek tools in an MCP proxy turns a markdown file into an Rspec test runner, just by reading the file. And that same {{include:}} lets me drop that pattern anywhere I want all over the graph, which is pretty neat.
Obie's definitely on to something with this. There's a rather lot of negative emotion surrounding the changes to our profession. There's a certain lack of joy bleeding through many of the comments. Computing doesn't have to be that way, didn't used to be anyways. If you're smart about your verification process, if you're smart about optimizing the framing of your intent, this isn't a scary world we're all crashing headlong into. Remember what they're for - they're generative not thinking - and they'll serve you well.
Or not
They can be little gooses sometimes ;)
I can’t read past a few paragraphs because medium puts an annoying pop up that takes most of the screen and I can’t close.
What’s worse than snake oil sellers? Snake oil sellers powered by LLM.
> Most of all, it promised a much bigger paycheck!
Tell us about this part, son, so far you’ve been only spewing same Agile/Xtreme shite we’ve been hearing for decades.
I am new. What is wrong with the Agile/Xtreme stuff?
The snake oil salesmen who turn it into a religion/cult. The ceremony that doesn't bring any advantages. The irrational adherence to this ceremony.
"Agile/XP" is a big bag of many ideas. Some of them aren't related, but they all get stuffed in that bag.
Personally, I enjoy pair programming, which is the literal experience of dealing with an (agentic) AI for the purpose of programming.
Tests (regression tests, unit tests, integration tests, ...) make development easier in that they tell you right away when you took a wrong step. You don't have to test manually anymore, so that saves you time and concentration, and you can test a lot more often.
Those are the good bits of "Agile/XP".
Tl;dr?
Author argues that values long embedded in Ruby culture (testing, readability, design) are very useful for collaborating with AI, gives an example os asking Claude to follow tdd
Ruby does have the best testing tooling of any I’ve tried. But I feel like it’s half to make up for how horribly unreliable the language is. The whole thing being untyped makes it borderline impossible to know the code is correct without unit tests covering everything.
"Untyped" means, for example, you can't tell a string from a number, because they are the same type.
You mean "not statically typed". Which also applies to Javascript, PHP, Python, ... so if that critique doesn't stick to those, it's not a critique you can level at Ruby.
Typescript has almost universal adoption at companies now. PHP I can’t imagine any company choosing for new work anymore. And Python I’m not terribly familiar with but it does seem to be moving towards types.
Ruby behaves sensibly through the principle of least surprise.
But it does have extremely powerful metaprogramming capabilities which are regularly abused by those not wise enough to know that just because you could do something doesn't mean that you should.
I regularly code in a variety of languages from C / C++ through Python and Ruby through to Haskell. They all have their advantages and disadvantages. All of them are capable of abuse by the sufficiently determined. And unit tests are helpful in all of them.
It’s quite surprising when you update Rails and they have changed the arguments for some obscure function used in only one place deep in your app and you get no indication of this until the actual line of code is run and it blows up.
I’ve worked on rails apps for the last 9 years and I’d guess 80% of the bugs that show up on production would have been flagged by typescript.
> until the actual line of code is run...
Which is what the Ruby test-heavy culture is all about. I prefer types for this very reason; the compiler/checker is a complete suite of testing I don't have to write.
I’ve seen large Ruby projects with hunders of developers working on it for >10 years with almost 100% sorbet coverage. It’s just that in Ruby you have to pay (ie spend extra time) for decent degree of type safety.