Building on vibes: Lessons from three years with LLMs(world.hey.com)
world.hey.com
Building on vibes: Lessons from three years with LLMs
https://world.hey.com/joaoqalves/building-on-vibes-lessons-from-three-years-with-llms-564f2801
4 comments
Why is this article only about small side projects? Is the crew of 70 in the OP’s day job not using GenAI for coding, and if so why not?
Hi! Thanks for the comment. Indeed, some, if not most, are using LLMs in their daily activities. They have access to GitHub copilot, and there were pilots with other tools like Claude Code, recently.
Generally speaking, these folks are empowered to make their lives better and more productive through LLMs. There are a few things to consider, though:
1. It’s not the same a brand new codebase vs a big, existing one. Context management helps, but you also need to invest a lot on it. Especially legacy projects. Bear in mind that producing code is part of the job of a Software Engineer but not the biggest chunk, especially in legacy apps. Observability, setting up good cloud infrastructure, etc is still there. I think there’s also room to improve it with LLMs but we must also acknowledge we’re in the early days, although it does not seem so.
2. When you work for a bigCo, there are tempos. Approvals, budget, licenses… All of this makes the adoption of these tools a bit slower than wanted.
3. Finally, there’s a cultural change. A lot of great SWE, even on HN, despise the idea of having someone writing code for them. “It’s bad code”, etc. We need, as an industry, to make sure we get the most out of the available tools, and be proficient with them. So, this is a more cultural/people’s problems. And these are harder than vibe coding.
Generally speaking, these folks are empowered to make their lives better and more productive through LLMs. There are a few things to consider, though:
1. It’s not the same a brand new codebase vs a big, existing one. Context management helps, but you also need to invest a lot on it. Especially legacy projects. Bear in mind that producing code is part of the job of a Software Engineer but not the biggest chunk, especially in legacy apps. Observability, setting up good cloud infrastructure, etc is still there. I think there’s also room to improve it with LLMs but we must also acknowledge we’re in the early days, although it does not seem so.
2. When you work for a bigCo, there are tempos. Approvals, budget, licenses… All of this makes the adoption of these tools a bit slower than wanted.
3. Finally, there’s a cultural change. A lot of great SWE, even on HN, despise the idea of having someone writing code for them. “It’s bad code”, etc. We need, as an industry, to make sure we get the most out of the available tools, and be proficient with them. So, this is a more cultural/people’s problems. And these are harder than vibe coding.
I’ve spent the past three years "vibe coding" with LLMs, building side projects I wouldn’t have had time to ship otherwise. Along the way, I’ve learned how to structure context for ChatGPT, utilize PRDs to minimize rework, and address areas of weakness, such as testing.
It doesn’t feel like "magic" anymore, but it does feel like a real productivity boost. Wrote up the reflections + shipped projects in this blog post.
Happy to hear your thoughts and comments.
It doesn’t feel like "magic" anymore, but it does feel like a real productivity boost. Wrote up the reflections + shipped projects in this blog post.
Happy to hear your thoughts and comments.
Similar experience. It is a productivity boost. I still don't like the verbosity of most models.
I find writing prompts quite annoying and sometimes importing/exporting the context I am working with is more work than just implementing it myself or by prompting for partial problems.
I don't like to become dependent on third party models though, so I prefer local solutions. For company work I use Claude and Chatty since I got licenses here.
But my home brew solution is getting there too.
I find writing prompts quite annoying and sometimes importing/exporting the context I am working with is more work than just implementing it myself or by prompting for partial problems.
I don't like to become dependent on third party models though, so I prefer local solutions. For company work I use Claude and Chatty since I got licenses here.
But my home brew solution is getting there too.