6 ms·

I don't want to be that contrarian guy, but I find it energizing to go faster. For example, being able to blast through a list of niggling defects that need to

by Zigurd 11mo ago

I don't want to be that contrarian guy, but I find it energizing to go faster. For example, being able to blast through a list of niggling defects that need to be fixed is no longer a stultifying drag. I recently used a coding agent on a project where I was using an unfamiliar language, framework, API, and protocol. It was a non-trivial project, and I had to be paying attention to what the agent was doing because it definitely would go off into the weeds fairly often. But not having to spend hours here and there getting up to speed on some mundane but unfamiliar aspect of the implementation really made everything about the experience better. I even explored some aspects of LLM performance: I could tell that new and fast changing APIs easily flummox a coding agent, confirming the strong relationship of up-to-date and accurate training material to LLM performance. I've also seen this aspect of agent assisted coding improve and vary across AIs.

vidarh 11mo ago
Same here. I've picked up projects that have languished for years because the boring tasks no longer make me put them aside.
Avicebron 11mo ago
Can you share why it was non-trivial? I'm curious about how folks are evaluating the quality of their solutions when the project space is non trivial and unfamiliar
- ares623 11mo ago
  A little bit of Dunning-Kruger maybe?
  - joseda-hg 11mo ago
    Non triviality is relative anyway, if anything admiting complexity beyond your skills on your expertise field reads like the inverse
  - marginalia_nu 11mo ago
    Dunning-Kruger isn't what you think it is[1] [1] https://skepchick.org/2020/10/the-dunning-kruger-effect-misunderstood-misrepresented-overused-and-non-existent/ https://skepchick.org/2020/10/the-dunning-kruger-effect-misu...
- Zigurd 11mo ago
  It's a real, complete, social media client app. Not a huge project. But the default app was clearly written by multiple devs, each with their own ideas. One goal was to be cleaner and more orthogonal, among other goals.
skdhshdd 11mo ago
> But not having to spend hours here and there getting up to speed on some mundane but unfamiliar aspect of the implementation At some point you realize if you want people to trust you you have to do this. Otherwise you’re just gambling, which isn’t very trustworthy. It’s also got the cumulative effect of making you a good developer if done consistently over the course of your career. But yes, it’s annoying and slow in the short term.
louthy 11mo ago
> But not having to spend hours here and there getting up to speed on some mundane but unfamiliar aspect of the implementation Red flag. In other words you don’t understand the implementation well enough to know if the AI has done a good job. So the work you have committed may work or it may have subtle artefacts/bugs that you’re not aware of, because doing the job properly isn’t of interest to you. This is ‘phoning it in’, not professional software engineering.
- jmalicki 11mo ago
  Learning an unfamiliar aspect and doing it be hand will have the same issues. If you're new to Terraform, you are new to Terraform, and are probably going to even insert more footguns than the AI. At least when the AI does it you can review it.
  - pferde 11mo ago
    No, you can not. Without understanding the technology, at best you can "vibe-review" it, and determine that it "kinda sorta looks like it's doing what it's supposed to do, maybe?".
  - louthy 11mo ago
    > Learning an unfamiliar aspect and doing it be hand will have the same issues. If you're new to Terraform, you are new to Terraform Which is why you spend time upfront becoming familiar with whatever it is you need to implement. Otherwise it’s just programming by coincidence [1], which is how amateurs write code. > and are probably going to even insert more footguns than the AI. Very unlikely. If I spend time understanding a domain then I tend to make fewer errors when working within that domain. > At least when the AI does it you can review it. You can’t review something you don’t understand. [1] https://dev.to/decoeur_/programming-by-coincidence-dont-do-it-7cp https://dev.to/decoeur_/programming-by-coincidence-dont-do-i...
  - lelanthran 11mo ago
    > Learning an unfamiliar aspect and doing it be hand will have the same issues. I don't think so. We gain proficiency by doing, not by reading. If all you are doing is reading, you are not gaining much.
observationist 11mo ago
There's something exhilarating about pushing through to some "everything works like I think it should" point, and you can often get there without doing the conscientious, diligent, methodical "right" way of doing things, and it's only getting easier. At the point where everything works, if it's not just a toy or experiment, you definitely have to go back and understand everything. There will be a ton to fix, and it might take longer to do it like that than just by doing it right the first time. I'm not a professional SWE, I just know enough to understand what the right processes look like, and vibe coding is awesome but chaotic and messy.
- lukan 11mo ago
  "It was a non-trivial project, and I had to be paying attention to what the agent was doing" There is a big difference between vibe coding and llm assisted coding and the poster above seems to be aware of it.
  - closewith 11mo ago
    Vibe coding is the name for LLM assisted coding, whether you like it or not.
    - Nashooo 11mo ago
      One means (used to mean?) actually checking the LLM's output one means keep trying until it outputs does what you want.
      - iwontberude 11mo ago
        Given that the models will attempt to check their own work with almost the identical verification that a human engineer would, it's hard to say if human's aren't implicitly checking by relying on the shared verification methods (e.g. let me run the tests, let me try to run the application with specific arguments to test if the behavior works).
        11mo ago
Rperry2174 11mo ago
I think both experience are true. AI removes boredome AND removes the natural pauses where understanding used to form.. energy goes up, but so does the kind of "compression" of cognitive things. I think its less a quesiton of "faster" or "slower" but rather who controls the tempo
- visarga 11mo ago
  After 4 hours of vibe coding I feel as tired as a full day of manual coding. The speed can be too much. If I only use it for a few minutes or an hour, it feels energising.
- agumonkey 11mo ago
  > the kind of "compression" of cognitive things compression is exactly what is missing for me when using agents, reading their approach doesn't let me compress the model in my head to evaluate it, and that was why i did programming in the first place.
stuffn 11mo ago
I think the counter-point to that is what I experience. I agree it can be energizing because you can offload the bullshit work to a robot. For example, build me a CRUD app with a bootstrap frontend. Highly useful stuff especially if this isn't your professional forte. The problems come afterwards: 1. The bigger the base codebase generation the less likely you're going to find time or energy to refactor LLM slop into something maintainable. I've spent a lot of time tailoring prompts for this type of generation and still can't get the code to be as precise as something an engineer would write. 2. Using an unfamiliar language means you're relying entirely on the LLM to determine what is safe. Suppose you wish to generate a project in C++. An LLM will happily do it. But will it be up to a standard that is maintainable and safe? Probably not. The devil is in the mundane details you don't understand. In the case of (2) it's likely more instructive to have the LLM make you do the leg work, and then it can suggest simple verifiable changes. In the case of (1) I think it's just an extension of the complexity of any project professional or not. It's often better to write it correct the first time than write it fast and loose and then find the time to fix it later.
- OptionOfT 11mo ago
  Ergo instant tech debt.
Animats 11mo ago
> I don't want to be that contrarian guy, but I find it energizing to go faster. You, too, can be awarded the Order of Labor Glory, Third Class.[1] [1] https://en.wikipedia.org/wiki/Order_of_Labour_Glory https://en.wikipedia.org/wiki/Order_of_Labour_Glory
- Zigurd 11mo ago
  Had I been doing other than interesting exploratory coding, I would agree with you. I can readily imagine standups where the "scrum master" asks where our AI productivity boost numbers are. Big dystopia potential.
  - p_v_doom 11mo ago
    People in some places already are doing that. The Dystopia is now
pyrophane 11mo ago
> I recently used a coding agent on a project where I was using an unfamiliar language, framework, API, and protocol. You didn’t find that to be a little too much unfamiliarity? With the couple of projects that I’ve worked on that were developed using an “agent first” approach I found that if I added too many new things at once it would put me in a difficult space where I didn’t feel confident enough to evaluate what the agent was doing, and when it seemed to go off the rails I would have to do a bunch of research to figure out how to steer it. Now, none of that was bad, because I learned a lot, and I think it is a great way to familiarize oneself with a new stack, but if I want to move really fast, I still pick mostly familiar stuff.
- QuercusMax 11mo ago
  I'm assuming this is the case where they are working in an existing codebase written by other humans. I've been in this situation a lot recently, and Copilot is a pretty big help to figure out particularly fiddly bits of syntax - but it's also really stupid suggests a lot of stuff that doesn't work at all.
- Zigurd 11mo ago
  SwiftKotlinDartGo blur together by now. That's too many languages but what are you gonna do? I was ready to find that it was a bit much. The conjunction of ATProto and Dart was almost too much for the coding agent to handle and stay useful. But in the end it was OK. I went from "wow that flutter code looks weird" to enjoying it pretty quickly.
- stonemetal12 11mo ago
  > I didn’t feel confident enough to evaluate what the agent was doing So don't. It is vibe coding, not math class. As long as it looks like it works then all good.
  - tjr 11mo ago
    Is there any software you think should not be developed with this approach?
OptionOfT 11mo ago
If you do this on your personal stuff, eh, I wouldn't do it, but you do you. But we're seeing that this becomes OK in the workplace, and I don't believe it is. If you propose these changes that would've normally taken you 2 weeks as your own in a PR, then I, as the reviewer, don't know where your knowledge ends and the AI's hallucinations begin. Do you need to do all of these things? Or is it because the most commonly forked template of this piece of code has this in its boilerplate? I don't know. Do you? How can you make sure the code works in all situations if you aren't even familiar with the language, let alone the framework / API and protocol? * Do you know that in Java you have to do string.Equals instead of == for equality? * Do you know in Python that you assigning a new value to a function default persists beyond the function? * And in JavaScript it does not? * Do you know that the C# && does not translate to VB.NET's And?
- QuercusMax 11mo ago
  A lot of that stuff can be handled by linters and static analysis tools.
  - seattle_spring 11mo ago
    What are some examples of linters / static analysis catching hallucinated solutions to problems? I feel like it would just yield a well-formatted, type safe incorrect solution, which is no better than a tangled mess.
    - steveklabnik 11mo ago
      A specific example: for some reason, when working on Playwright scripts, Claude really likes to inject await page.waitForLoadState('networkidle'); But this isn't good, and is not encouraged. So much so that there's an eslint that suggests removing it. This means that by running the linter, if Claude does decide to inject this, it gets taken out, because the linter runs and then tells it so.
- frio 11mo ago
  This is far and away the biggest problem I have atm. Engineers blowing through an incredible amount of work in a short time, but when an inevitable bug bubbles up (which would happen without AI!), there's noone to question. "Hey, you changed the way transactionality was handled here, and that's made a really weird race condition happen. Why did you change it? What edge case were you trying to handle?" -- "I don't know, the AI did it". This makes chasing things down exponentially harder. This has always been a problem in software engineering; of course -- sometimes staff have left, so you have to dig through tickets, related commits and documentation to intuit intent. But I think it's going to make for very weird drags on productivity in _new_ code that may not counter the acceleration LLMs provide, but will certainly exist.
sixothree 11mo ago
I am currently only vibe-coding my hobby projects. So if that changes, my view could very well change. But I 100% agree. It's liberating to focus on the design of my project, and my mental model can be of how I want things to work. It feels like that switch to test driven development where you start from the expected result and worry about the details later.
blitz_skull 11mo ago
I think it's less "going fast" and more "going fast forever." To your point, you can blow through damn-near anything pretty quickly now. Now I actually find myself problem-solving for nearly 8 hours every day. My brain feels fried at the end of the day way more than it used to.
- wiether 11mo ago
  Same feeling here! I used to be like: "well, this thing will take me at least half a day, it's already 16:00, so I'll better do something quiet to cooldown to the end of the day and tackle this issue tomorrow". I'll leave the office in an regular mood and take the night to get ready for tomorrow. Now I'm like: "17:30? 30 minutes? I have time to tackle another issue today!" I'll leave the office exhausted and take the night to try and recover from the day I had.
- solumunus 11mo ago
  This. I’m able to be more productive for long hours more consistently than before. The occasions where I’m engineering for 8 solid hours are much more frequent now, and I’m certainly more tired. Almost all of my time is now dedicated to problem solving and planning, the LLM executes and I sit there thinking. Not everyone’s brain or project is well suited for this, but for me as a personality combined with the way my product is structured, it’s a total game changer.
quotemstr 11mo ago
> I don't want to be that contrarian guy, but I find it energizing to go faster. For example, being able to blast through a list of niggling defects that need to be fixed is no longer a stultifying drag. It's often that just getting started at all on a task is the hardest part. That's why writers often produce a "vomit draft" (https://thewritepractice.com/vomit-first-draft/ https://thewritepractice.com/vomit-first-draft/) just to get into the right frame of mind to do real writing. Using a coding agent to fix something trivial serves the same purpose.
etothet 11mo ago
I 100% agree. It's been incredible for velocity and the capabilities and accuracy of the models I've been (mostly from Anthropic) have improved immensely over the last few months.
WhyOhWhyQ 11mo ago
Everyone in this conversation talks about different activities. One version of vibe coding happens with Netflix open and without ever opening a text editor, and another happens with thoroughly reviewing every change.
rightbyte 11mo ago
> I don't want to be that contrarian guy, but I find it energizing to go faster. Is that contrarian though? Seems like pretty normal corparate setting bragging to me. (Note: I am not accusing you of it since your boss or collegues does not read this). On the variant of "I am bad at not working too hard".
lelanthran 11mo ago
> I don't want to be that contrarian guy, but I find it energizing to go faster. For example, being able to blast through a list of niggling defects that need to be fixed is no longer a stultifying drag. It depends. No one is running their brain at full-throttle for more than a few hours on end. If your "niggling" defects is mostly changes that don't require deep thought (refactor this variable name, function parameters/return type changes, classes, filename changes, etc), then I can see how it is energising - you're getting repeated dopamine hits for very little effort. If, OTOH, you are doing deep review of the patterns and structures the LLM is producing, you aren't going to be doing that for more than a few hours without getting exhausted. I find, myself, that repeatedly correcting stuff makes me tired faster than simply "LGTM, lets yolo it!" on a filename change, or class refactor, etc. When the code I get is not what I wanted even though it passes the tests, it's more mental energy to correct the LLM than if I had simply done it myself from the first. A good example of the exhausting tasks from today - my input has preprocessing directives embedded in it; there's only three now (new project), so the code generated by Claude did a number of `if-then-else-if` statements to process this input. My expectation was that it would use a jump table of some type (possibly a dictionary holding function pointers, or a match/switch/case statement). I think a good analogy is self-driving cars: if the SDC requires no human intervention, then sure it's safe. If the SDC requires the human to keep their hand on the wheel at all time because it might disengage with sub-second warnings, then I'm going to be more tired after a long drive than if I simply turned it off.

by Zigurd 11mo ago

vidarh 11mo ago

Same here. I've picked up projects that have languished for years because the boring tasks no longer make me put them aside.

Avicebron 11mo ago

Can you share why it was non-trivial? I'm curious about how folks are evaluating the quality of their solutions when the project space is non trivial and unfamiliar

ares623 11mo ago
A little bit of Dunning-Kruger maybe?
- joseda-hg 11mo ago
  Non triviality is relative anyway, if anything admiting complexity beyond your skills on your expertise field reads like the inverse
- marginalia_nu 11mo ago
  Dunning-Kruger isn't what you think it is[1] [1] https://skepchick.org/2020/10/the-dunning-kruger-effect-misunderstood-misrepresented-overused-and-non-existent/ https://skepchick.org/2020/10/the-dunning-kruger-effect-misu...
Zigurd 11mo ago
It's a real, complete, social media client app. Not a huge project. But the default app was clearly written by multiple devs, each with their own ideas. One goal was to be cleaner and more orthogonal, among other goals.

skdhshdd 11mo ago

> But not having to spend hours here and there getting up to speed on some mundane but unfamiliar aspect of the implementation At some point you realize if you want people to trust you you have to do this. Otherwise you’re just gambling, which isn’t very trustworthy. It’s also got the cumulative effect of making you a good developer if done consistently over the course of your career. But yes, it’s annoying and slow in the short term.

louthy 11mo ago

> But not having to spend hours here and there getting up to speed on some mundane but unfamiliar aspect of the implementation Red flag. In other words you don’t understand the implementation well enough to know if the AI has done a good job. So the work you have committed may work or it may have subtle artefacts/bugs that you’re not aware of, because doing the job properly isn’t of interest to you. This is ‘phoning it in’, not professional software engineering.

jmalicki 11mo ago
Learning an unfamiliar aspect and doing it be hand will have the same issues. If you're new to Terraform, you are new to Terraform, and are probably going to even insert more footguns than the AI. At least when the AI does it you can review it.
- pferde 11mo ago
  No, you can not. Without understanding the technology, at best you can "vibe-review" it, and determine that it "kinda sorta looks like it's doing what it's supposed to do, maybe?".
- louthy 11mo ago
  > Learning an unfamiliar aspect and doing it be hand will have the same issues. If you're new to Terraform, you are new to Terraform Which is why you spend time upfront becoming familiar with whatever it is you need to implement. Otherwise it’s just programming by coincidence [1], which is how amateurs write code. > and are probably going to even insert more footguns than the AI. Very unlikely. If I spend time understanding a domain then I tend to make fewer errors when working within that domain. > At least when the AI does it you can review it. You can’t review something you don’t understand. [1] https://dev.to/decoeur_/programming-by-coincidence-dont-do-it-7cp https://dev.to/decoeur_/programming-by-coincidence-dont-do-i...
- lelanthran 11mo ago
  > Learning an unfamiliar aspect and doing it be hand will have the same issues. I don't think so. We gain proficiency by doing, not by reading. If all you are doing is reading, you are not gaining much.

observationist 11mo ago

There's something exhilarating about pushing through to some "everything works like I think it should" point, and you can often get there without doing the conscientious, diligent, methodical "right" way of doing things, and it's only getting easier. At the point where everything works, if it's not just a toy or experiment, you definitely have to go back and understand everything. There will be a ton to fix, and it might take longer to do it like that than just by doing it right the first time. I'm not a professional SWE, I just know enough to understand what the right processes look like, and vibe coding is awesome but chaotic and messy.

lukan 11mo ago
"It was a non-trivial project, and I had to be paying attention to what the agent was doing" There is a big difference between vibe coding and llm assisted coding and the poster above seems to be aware of it.
- closewith 11mo ago
  Vibe coding is the name for LLM assisted coding, whether you like it or not.
  - Nashooo 11mo ago
    One means (used to mean?) actually checking the LLM's output one means keep trying until it outputs does what you want.
    - iwontberude 11mo ago
      Given that the models will attempt to check their own work with almost the identical verification that a human engineer would, it's hard to say if human's aren't implicitly checking by relying on the shared verification methods (e.g. let me run the tests, let me try to run the application with specific arguments to test if the behavior works).
      - 11mo ago

Rperry2174 11mo ago

I think both experience are true. AI removes boredome AND removes the natural pauses where understanding used to form.. energy goes up, but so does the kind of "compression" of cognitive things. I think its less a quesiton of "faster" or "slower" but rather who controls the tempo

visarga 11mo ago
After 4 hours of vibe coding I feel as tired as a full day of manual coding. The speed can be too much. If I only use it for a few minutes or an hour, it feels energising.
agumonkey 11mo ago
> the kind of "compression" of cognitive things compression is exactly what is missing for me when using agents, reading their approach doesn't let me compress the model in my head to evaluate it, and that was why i did programming in the first place.

stuffn 11mo ago

I think the counter-point to that is what I experience. I agree it can be energizing because you can offload the bullshit work to a robot. For example, build me a CRUD app with a bootstrap frontend. Highly useful stuff especially if this isn't your professional forte. The problems come afterwards: 1. The bigger the base codebase generation the less likely you're going to find time or energy to refactor LLM slop into something maintainable. I've spent a lot of time tailoring prompts for this type of generation and still can't get the code to be as precise as something an engineer would write. 2. Using an unfamiliar language means you're relying entirely on the LLM to determine what is safe. Suppose you wish to generate a project in C++. An LLM will happily do it. But will it be up to a standard that is maintainable and safe? Probably not. The devil is in the mundane details you don't understand. In the case of (2) it's likely more instructive to have the LLM make you do the leg work, and then it can suggest simple verifiable changes. In the case of (1) I think it's just an extension of the complexity of any project professional or not. It's often better to write it correct the first time than write it fast and loose and then find the time to fix it later.

OptionOfT 11mo ago
Ergo instant tech debt.

Animats 11mo ago

> I don't want to be that contrarian guy, but I find it energizing to go faster. You, too, can be awarded the Order of Labor Glory, Third Class.[1] [1] https://en.wikipedia.org/wiki/Order_of_Labour_Glory https://en.wikipedia.org/wiki/Order_of_Labour_Glory

Zigurd 11mo ago
Had I been doing other than interesting exploratory coding, I would agree with you. I can readily imagine standups where the "scrum master" asks where our AI productivity boost numbers are. Big dystopia potential.
- p_v_doom 11mo ago
  People in some places already are doing that. The Dystopia is now

pyrophane 11mo ago

> I recently used a coding agent on a project where I was using an unfamiliar language, framework, API, and protocol. You didn’t find that to be a little too much unfamiliarity? With the couple of projects that I’ve worked on that were developed using an “agent first” approach I found that if I added too many new things at once it would put me in a difficult space where I didn’t feel confident enough to evaluate what the agent was doing, and when it seemed to go off the rails I would have to do a bunch of research to figure out how to steer it. Now, none of that was bad, because I learned a lot, and I think it is a great way to familiarize oneself with a new stack, but if I want to move really fast, I still pick mostly familiar stuff.

QuercusMax 11mo ago
I'm assuming this is the case where they are working in an existing codebase written by other humans. I've been in this situation a lot recently, and Copilot is a pretty big help to figure out particularly fiddly bits of syntax - but it's also really stupid suggests a lot of stuff that doesn't work at all.
Zigurd 11mo ago
SwiftKotlinDartGo blur together by now. That's too many languages but what are you gonna do? I was ready to find that it was a bit much. The conjunction of ATProto and Dart was almost too much for the coding agent to handle and stay useful. But in the end it was OK. I went from "wow that flutter code looks weird" to enjoying it pretty quickly.
stonemetal12 11mo ago
> I didn’t feel confident enough to evaluate what the agent was doing So don't. It is vibe coding, not math class. As long as it looks like it works then all good.
- tjr 11mo ago
  Is there any software you think should not be developed with this approach?

OptionOfT 11mo ago

If you do this on your personal stuff, eh, I wouldn't do it, but you do you. But we're seeing that this becomes OK in the workplace, and I don't believe it is. If you propose these changes that would've normally taken you 2 weeks as your own in a PR, then I, as the reviewer, don't know where your knowledge ends and the AI's hallucinations begin. Do you need to do all of these things? Or is it because the most commonly forked template of this piece of code has this in its boilerplate? I don't know. Do you? How can you make sure the code works in all situations if you aren't even familiar with the language, let alone the framework / API and protocol? * Do you know that in Java you have to do string.Equals instead of == for equality? * Do you know in Python that you assigning a new value to a function default persists beyond the function? * And in JavaScript it does not? * Do you know that the C# && does not translate to VB.NET's And?

QuercusMax 11mo ago
A lot of that stuff can be handled by linters and static analysis tools.
- seattle_spring 11mo ago
  What are some examples of linters / static analysis catching hallucinated solutions to problems? I feel like it would just yield a well-formatted, type safe incorrect solution, which is no better than a tangled mess.
  - steveklabnik 11mo ago
    A specific example: for some reason, when working on Playwright scripts, Claude really likes to inject await page.waitForLoadState('networkidle'); But this isn't good, and is not encouraged. So much so that there's an eslint that suggests removing it. This means that by running the linter, if Claude does decide to inject this, it gets taken out, because the linter runs and then tells it so.
frio 11mo ago
This is far and away the biggest problem I have atm. Engineers blowing through an incredible amount of work in a short time, but when an inevitable bug bubbles up (which would happen without AI!), there's noone to question. "Hey, you changed the way transactionality was handled here, and that's made a really weird race condition happen. Why did you change it? What edge case were you trying to handle?" -- "I don't know, the AI did it". This makes chasing things down exponentially harder. This has always been a problem in software engineering; of course -- sometimes staff have left, so you have to dig through tickets, related commits and documentation to intuit intent. But I think it's going to make for very weird drags on productivity in _new_ code that may not counter the acceleration LLMs provide, but will certainly exist.

sixothree 11mo ago

I am currently only vibe-coding my hobby projects. So if that changes, my view could very well change. But I 100% agree. It's liberating to focus on the design of my project, and my mental model can be of how I want things to work. It feels like that switch to test driven development where you start from the expected result and worry about the details later.

blitz_skull 11mo ago

I think it's less "going fast" and more "going fast forever." To your point, you can blow through damn-near anything pretty quickly now. Now I actually find myself problem-solving for nearly 8 hours every day. My brain feels fried at the end of the day way more than it used to.

wiether 11mo ago
Same feeling here! I used to be like: "well, this thing will take me at least half a day, it's already 16:00, so I'll better do something quiet to cooldown to the end of the day and tackle this issue tomorrow". I'll leave the office in an regular mood and take the night to get ready for tomorrow. Now I'm like: "17:30? 30 minutes? I have time to tackle another issue today!" I'll leave the office exhausted and take the night to try and recover from the day I had.
solumunus 11mo ago
This. I’m able to be more productive for long hours more consistently than before. The occasions where I’m engineering for 8 solid hours are much more frequent now, and I’m certainly more tired. Almost all of my time is now dedicated to problem solving and planning, the LLM executes and I sit there thinking. Not everyone’s brain or project is well suited for this, but for me as a personality combined with the way my product is structured, it’s a total game changer.

quotemstr 11mo ago

> I don't want to be that contrarian guy, but I find it energizing to go faster. For example, being able to blast through a list of niggling defects that need to be fixed is no longer a stultifying drag. It's often that just getting started at all on a task is the hardest part. That's why writers often produce a "vomit draft" (https://thewritepractice.com/vomit-first-draft/ https://thewritepractice.com/vomit-first-draft/) just to get into the right frame of mind to do real writing. Using a coding agent to fix something trivial serves the same purpose.

etothet 11mo ago

I 100% agree. It's been incredible for velocity and the capabilities and accuracy of the models I've been (mostly from Anthropic) have improved immensely over the last few months.

WhyOhWhyQ 11mo ago

Everyone in this conversation talks about different activities. One version of vibe coding happens with Netflix open and without ever opening a text editor, and another happens with thoroughly reviewing every change.

rightbyte 11mo ago

> I don't want to be that contrarian guy, but I find it energizing to go faster. Is that contrarian though? Seems like pretty normal corparate setting bragging to me. (Note: I am not accusing you of it since your boss or collegues does not read this). On the variant of "I am bad at not working too hard".

lelanthran 11mo ago

> I don't want to be that contrarian guy, but I find it energizing to go faster. For example, being able to blast through a list of niggling defects that need to be fixed is no longer a stultifying drag. It depends. No one is running their brain at full-throttle for more than a few hours on end. If your "niggling" defects is mostly changes that don't require deep thought (refactor this variable name, function parameters/return type changes, classes, filename changes, etc), then I can see how it is energising - you're getting repeated dopamine hits for very little effort. If, OTOH, you are doing deep review of the patterns and structures the LLM is producing, you aren't going to be doing that for more than a few hours without getting exhausted. I find, myself, that repeatedly correcting stuff makes me tired faster than simply "LGTM, lets yolo it!" on a filename change, or class refactor, etc. When the code I get is not what I wanted even though it passes the tests, it's more mental energy to correct the LLM than if I had simply done it myself from the first. A good example of the exhausting tasks from today - my input has preprocessing directives embedded in it; there's only three now (new project), so the code generated by Claude did a number of `if-then-else-if` statements to process this input. My expectation was that it would use a jump table of some type (possibly a dictionary holding function pointers, or a match/switch/case statement). I think a good analogy is self-driving cars: if the SDC requires no human intervention, then sure it's safe. If the SDC requires the human to keep their hand on the wheel at all time because it might disengage with sub-second warnings, then I'm going to be more tired after a long drive than if I simply turned it off.