Needless country club chicanery.
Vibe engineering
571–580 of 759 posts
Re: Vibe engineering
#572Earlier quoted context omitted.
> Your carefully curated AGENTS.md is only really useful at the very beginning of the conversation, but the longer the conversation gets, the less important those tokens on the top are. If that's genuinely causing you problems you can restart your session frequently to avoid the context rot.
Come on, let's not pretend 100k tokens is something I need to spend hours to reach for your helpful advice to be even remotely valid, it's something even the most basic problems struggle to fit into. For the fun of it I just started a new conversation with Sonnet 4, passed it one 550 lines long file (25 kilobytes) and my AGENTS.md ( I then asked it to re-write a part of it to "make it look better" (184 lines added, 1…
Thanks for bringing numbers. I realize now I've not actually done much customization of AGENTS.md myself yet, so maybe I'll start seeing the problems you're describing more as I iterate on my own custom files.
Re: Vibe engineering
#573Marvelous, now all we need is "vibe civil engineering".
Re: Vibe engineering
#574Earlier quoted context omitted.
I think people underestimate the degree to which fun matters when it comes to productivity. If something isn’t fun then I’ll likely put it off. A 15 minute task can become hours, maybe days long, because I’m going to procrastinate on doing it. If managing a bunch of AI agents is a very un-fun way to spend time, then I don’t think it’s the future. If the new way of doing this is more work and more tedium, then why the…
I think some people have more fun using LLM agents and generative AI tools. Not my case, but you can definitely read a bunch of comments from people using the tools and having fun/experience a state of flow like they have never had before
I definitely agree with you there. I contracted with a company that had some older engineers who were in largely managerial roles who really liked using AI for personal projects, and honestly, I kind of get it. Their work flow was basically prompt, get results, prompt again with modifications, rinse and repeat, it's low effort and has a nice REPL-like loop. Paraphrasing a bit, but it basically re-kindled the joy of programming for them.
Haven't gotten the chance to ask, but I imagine managing a team of AI agents would feel a little too much like their day job, and consequently, suck the fun out of it.
That said, looking back, I think the reason why generative AI is so fun for so many coders is because programming has become unnecessarily complex. I have to admit, programming nowadays for me feels like a bit of a slog at times because of the sheer effort it can sometimes take to implement the simplest things. Doesn't have to be that way, but I think LLM copy-paste machines are probably the wrong direction.
Re: Vibe engineering
#575Earlier quoted context omitted.
I reset context probably every 5-10 minutes if not more frequently, and commit even more often than that. If you’re going 5 hours between commits or context resets, I’m not surprised you’re getting bad results. If you ever see “summarizing”’in copilot for example, that means you went way too far in that context window. The LLMs get increasingly inaccurate and confused as the context window fills up. Other things like…
The 'best' trick I learned from someone over here when working with Claude Code is to very regularly go back a few steps in your context (esc esc -> pick something a few steps up) and say something like "yeah, I already did this myself, now continue and do Y" It results helps keep the context clean while still keeping the initial context I provided (usually with documentation and initial plan setup) at the core of th…
Now that's dangerous to do because the conversation history in Claude Code now also reverts the code to that point. So while this technique may have worked in the past, it no longer works.
Re: Vibe engineering
#576Re: Vibe engineering
#577I just feel so discouraged reading this somehow. I used to have this hard-to-get, in-demand skill that paid lots of money and felt like even though programming languages, libraries and web frameworks were always evolving I could always keep up because I'm smart. But now with these people like Simon Willison writing about the new way of coding with these agents and multiple streams of work going on at a time and it so…
I think people underestimate the degree to which fun matters when it comes to productivity. If something isn’t fun then I’ll likely put it off. A 15 minute task can become hours, maybe days long, because I’m going to procrastinate on doing it. If managing a bunch of AI agents is a very un-fun way to spend time, then I don’t think it’s the future. If the new way of doing this is more work and more tedium, then why the…
I’ll be that voice I guess - I have fun “vibe coding”.
I’m a professional software engineer in Silicon Valley, and I’m fortunate to have been able to work on household-name consumer products across my career. I definitely know how to do “real” professional work “at scale” or whatever. Point is, I can do real work and understand things on my own, and I can generally review code and guide architecture and all that jazz. I became a software engineer because I love creating things that I and others could use, and I don’t care about “solving the puzzle” type satisfaction from writing code. In engineering school, software had the fastest turnaround time from idea in my head to something I could use, and that’s why I became a software engineer.
LLM assisted coding accelerates this trend. I can guide an LLM to help me create things quickly and easily. Things I can mostly create myself, of course, but I find it faster for a whole category of easy tasks like generating UIs. It really lowers the “activation energy” to experiment. I think of it like 3D printing, where I can prototype ideas in an afternoon instead of long weekend or a few weeks.
Re: Vibe engineering
#578I just feel so discouraged reading this somehow. I used to have this hard-to-get, in-demand skill that paid lots of money and felt like even though programming languages, libraries and web frameworks were always evolving I could always keep up because I'm smart. But now with these people like Simon Willison writing about the new way of coding with these agents and multiple streams of work going on at a time and it so…
I'm really sorry to hear this, because part of my goal here is to help push back against the idea that "programming skills are useless now, anyone can get an LLM to write code for them". I think existing software development skills get a whole lot more valuable with the addition of coding agents. You can take everything you've learned up to this point and accelerate the impact you can have with this new family of too…
This has been experience as well. If there is a hard problem which needs to be addressed, generative code helps me break the inertia by generating the first draft and then I get really curious to poke holes in the generated code. I tend to procrastinate when I come across a gnarly issue or something I am not really familiar with, justifying by saying I need a big block of time to work on it. I use generative code as a pushy "mom/boss/coworker/spouse" to get stuff done.
Re: Vibe engineering
#579Nah.
Software engineer.
Not vibe engineer. Not Java engineer. Not compiler engineer.
You either understand the computer and then can apply any fucking tool or methodology to solve a problem, or you’re out.
Re: Vibe engineering
#580Earlier quoted context omitted.
I'm not sure that having the patience to work with something with a very inconsistent performance and that frequently lies is an extension of existing development skills. It doesn't work like tools developers use and it doesn't work like people developers work with. Furthermore, techniques of working with agents today may be completely outdated a year from now. The acceleration is also inconsistent: sometimes there's…
> I'm not sure that having the patience to work with something with a very inconsistent performance and that frequently lies is an extension of existing development skills. If you’ve be been tasked with leadership of an engineering effort involving multiple engineers and stakeholders you know that this is in fact a crucial part of the role the more senior you get. It is much the same with people: know their limitatio…
Because I reached that position 15 years ago, I can tell you that this is untrue (in the sense that the experience is completely different from an LLM).
Training is one thing, but training doesn't increase the productivity of the trainer; it's meant to improve the capability of the trainee.
At any level of capability, though - whether we're talking about an intern after one year of university or a senior developer with 20 years of experience - effective management requires that you're able to trust that the person tells you when they've hit a snag or anything else you may need to know. We may not be talking 100% of trust, but not too far from that, either. You can't continue working with someone that doesn't tell you what you need to know even 10% of the time, regardless of their level. LLMs are not at that acceptable level yet, so the experience is not similar to technical leadership.
If you've ever been tasked with leading one or more significant projects you'd know that if you feel you have to review every line of code anyone on the team writes, at every step of the process, that's not the path to success (if you did that, not only would progress be slow, but your team wouldn't like you very much). Code review is a very important part of the process, but it's not an efficient mechanism for day-to-day communication.