My experience exactly. (including nearly 40 years of code exposure) I just wish there was an alternative to Claude sonnet 4. I see gemini pro 2.5 as a side girlfriend, but only Claude truly vibes with me.
Vibe coding as a coding veteran: from 8-bit assembly to English-as-code
41–50 of 132 posts
Re: Vibe coding as a coding veteran: from 8-bit assembly to English-as-code
#42I don't feel good doing it, but is anyone else feeling not capitalizing text, maintaining a slightly abrasive attitude, and consciously stealing credits, yield better results from coding agents? e.g. "i want xxx implemented, can you do", "ok you do" than "I'm wondering if..." etc.
Why not just:
"Implement xxx"
?
I don't think we can offend these things (yet).
Re: Vibe coding as a coding veteran: from 8-bit assembly to English-as-code
#43This was interesting. I still wonder, if (as the author mentions and I've seen in my experience) companies are pivoting to hiring more senior devs and fewer or no junior devs... ... where will the new generations of senior devs come from? If, as the author argues, the role of the knowledgeable senior is still needed to guide the AI and review the occasional subtle errors it produces, where will new generations of sen…
People keep saying this, but the young folks who start out with stuff are gonna surpass us old folks at some point. Us old folks just get a big head start. Right now we're comparing seniors who learned the old way to juniors who learned the old way. Soon we'll start having juniors who started out with this stuff. It also takes time to learn how to teach people to use tools. We're all still figuring out how to use the…
> Soon we'll start having juniors who started out with this stuff.
But who will hire them? Businesses are ramping down from hiring juniors, since apparently a few good seniors with AI can replace them (in the minds of the people doing the hiring).
Or is it that when all of the previous batch of seniors have retired or died of old age, businesses will have no option but to hire juniors trained "the new way", without a solid background to help them understand when AI solutions are flawed or misguided, and pray it all works out?
Re: Vibe coding as a coding veteran: from 8-bit assembly to English-as-code
#44I believe choosing a well known problem space in a well known language certainly influenced a lot of the behavior. AIs usefulness is correlated strongly with its training data and there’s no doubt been a significant amount of data about both the problem space and Python. I’d love to see how this compares when either the problem space is different or the language/ecosystem is different. It was a great read regardless!
100% this. I tried haskelling with LLMs and it’s performance is worse compared to Go. Although in fairness this was a year ago on GPT 3.5 IIRC
I wrote some Haskell using Claude. It was great.
Re: Vibe coding as a coding veteran: from 8-bit assembly to English-as-code
#45I believe choosing a well known problem space in a well known language certainly influenced a lot of the behavior. AIs usefulness is correlated strongly with its training data and there’s no doubt been a significant amount of data about both the problem space and Python. I’d love to see how this compares when either the problem space is different or the language/ecosystem is different. It was a great read regardless!
100% this. I tried haskelling with LLMs and it’s performance is worse compared to Go. Although in fairness this was a year ago on GPT 3.5 IIRC
I write Haskell with Claude Code and it's got remarkably good recently. We have some code at work that uses STM to have what is essentially a mutable state machine. I needed to split a state transition apart, and it did an admirable job. I had to intervene once or twice when it was going down a valid, but undesirable approach. This almost one shot performance was already a productivity boost, but didn't quite build. What I find most impressive now is the "fix" here is to literally have Claude run the build and see the errors. While GHC errors are verbose and not always the best it got everything building in a few more iterations. When it later got a test failure, I suggested we add a bit more logging - so it logged all state transitions, and spotted the unexpected transition and got the test passing. We really are a LONG way away from 3.5 performance.
Re: Vibe coding as a coding veteran: from 8-bit assembly to English-as-code
#46Earlier quoted context omitted.
100% this. I tried haskelling with LLMs and it’s performance is worse compared to Go. Although in fairness this was a year ago on GPT 3.5 IIRC
I'm not sure I'd say "100% this" if I was talking about GPT 3.5...
Yah, that’s a fair point.
I had assumed it’d remain relatively similar given that the training data would be smaller for languages like Haskell versus languages like Python & JavaScript.
Re: Vibe coding as a coding veteran: from 8-bit assembly to English-as-code
#47I believe choosing a well known problem space in a well known language certainly influenced a lot of the behavior. AIs usefulness is correlated strongly with its training data and there’s no doubt been a significant amount of data about both the problem space and Python. I’d love to see how this compares when either the problem space is different or the language/ecosystem is different. It was a great read regardless!
I've had a lot of good luck with Julia, on high performance data pipelines.
Re: Vibe coding as a coding veteran: from 8-bit assembly to English-as-code
#48Earlier quoted context omitted.
People keep saying this, but the young folks who start out with stuff are gonna surpass us old folks at some point. Us old folks just get a big head start. Right now we're comparing seniors who learned the old way to juniors who learned the old way. Soon we'll start having juniors who started out with this stuff. It also takes time to learn how to teach people to use tools. We're all still figuring out how to use the…
> Soon we'll start having juniors who started out with this stuff. But who will hire them? Businesses are ramping down from hiring juniors, since apparently a few good seniors with AI can replace them (in the minds of the people doing the hiring). Or is it that when all of the previous batch of seniors have retired or died of old age, businesses will have no option but to hire juniors trained "the new way", without a…
> But who will hire them?
Anyone who wants a competitive advantage?
My claim is that the gap between junior and senior has temporarily widened, which is why someone who previously would want to hire juniors might not right now. But I expect it will narrow as a generation that learned on this stuff comes into the fold, probably to a smaller gap than existed pre-LLM.
I think it will also narrow if the tools continue to get better.
Re: Vibe coding as a coding veteran: from 8-bit assembly to English-as-code
#49I don't feel good doing it, but is anyone else feeling not capitalizing text, maintaining a slightly abrasive attitude, and consciously stealing credits, yield better results from coding agents? e.g. "i want xxx implemented, can you do", "ok you do" than "I'm wondering if..." etc.
Why not just: "Implement xxx" ? I don't think we can offend these things (yet).
idk, my thinking is that sweatshop-slack-like inputs might correspond to more professional outcomes than exam-like questions as exams would be more likely to be solved by beginners. I also fear "Implement xxx" might be just too short, I feel they might like to have some bytes to map to outputs. Could very well be placebo as pointed out.
Re: Vibe coding as a coding veteran: from 8-bit assembly to English-as-code
#50What stands out for me, is that it was all possible thanks to the fact that the AI operator/conversationalist had enough knowledge to, more or less write, it all by hand, if he chose to.
Probably it was said many times already, but it will rather be the competition between programmers with AI and programmers without one, rather than no programmers with AI.
In particular, I love this part:
"I had serious doubts about the feasibility and efficiency of using inherently ambiguous natural languages as (indirect) programming tools, with a machine in between doing all the interpretation and translation toward artificial languages endowed with strict formal semantics. No more doubts: LLM-based AI coding assistants are extremely useful, incredibly powerful, and genuinely energising.
But they are fully useful and safe only if you know what you are doing and are able to check and (re)direct what they might be doing — or have been doing unbeknownst to you. You can trust them if you can trust yourself."