6 ms·

Where I work: - Development velocity is very noticeably much higher across the board. Quality is not obviously worse, but it's LLM assisted, not vibe coding (e

Where I work: - Development velocity is very noticeably much higher across the board. Quality is not obviously worse, but it's LLM assisted, not vibe coding (except for experiments and internal tools). - Things that would have been tactically built with TypeScript are now Rust apps. - Things that would have been small Python scripts are full web apps and dashboards. - Vibe coding (with Claude Desktop, nobody is using Replit or any of the others) is the new Excel for non tech people. - Every time someone has any idea it's accompanied by a multi page "Clauded" memo explaining why it's a great idea and what exactly should be done (about 20% of which is useful). - 80% of what were web searches now go to Claude instead (for at least a significant minority of people, could easily be over 50%). - Nobody talks about ChatGPT any more. It's Claude or (sometimes) Gemini. - My main job isn't writing code but I try to keep Claude Code (both my personal and corpo accounts) and OpenCode (also almost always Claude, via Copilot) busy and churning away on something as close to 100% of the time as I can without getting in the way of my other priorities. We (~20 people) are probably using 2 orders of magnitude more inference than we were at the start of the year and it's consolidated away from cursor, ChatGPT and Claude to just be almost all Claude (plus a little Gemini as that's part of our Google Whateverspace plan and some people like it, mostly for non-engineering tasks). No idea if any of this will make things better, exactly, but I think we'd be at a severe competitive disadvantage if we dropped it all and went back how things were.

mullingitover 6mo ago
> - Development velocity is very noticeably much higher across the board It's an absolute tornado of PRs these days. Everyone making the most of these tools is effectively an engineering team lead.
- MrDarcy 6mo ago
  The CTO/VP of engineering role down is now singularly focused on keeping agents fed with a backlog of Linear issues. This is the new normal.
  - aenis 6mo ago
    As a CTO I can say that this is not my experience. My experience these days is fighting corporate bureaucracy and inertia to make sure we reap the benefits of faster coding. Feeding agents with work is not a problem. Building teams that use those tools effectively is the problem. (Say, shall we merge product and engineering teams? Do we start getting rid of people who refuse to use AI? What do we do with pentests? How do we strengthen the tools that do code analysis and weed out lazy devs who can now more easily pretend to be invested in their work? Stuff like this keeps me busy.
    - mullingitover 6mo ago
      > Do we start getting rid of people who refuse to use AI? I don't even think the bigger companies are going to waste time on figuring out how to retrain, they're just going to do industrial scale layoffs and then rebuild from the ground up with people who won't get past interviews without demonstrating hard skills in this area. There is a shocking gap growing right now, it's a Wile E. Coyote not realizing he already walked off the cliff type of situation for a lot of people.
      - eieie 6mo ago
        Lol people like you operate in a local maximum. Ultimately the shareholders want to see the money. They dont give a crap about what you think or what the poster above thinks - you're both accountable to the shareholders who do not employ you for fun. They employ you for the sole purpose of making them wealthier. All this incremental spend on tokens shows up in the financials positively or it doesn't.
        mullingitover 6mo ago
        > Ultimately the shareholders want to see the money. Seems like we're saying the same thing? > All this incremental spend on tokens shows up in the financials positively or it doesn't. Right, and we're talking about the staff failing to spend the incremental tokens at all, thus failing to discover whether or not they'll show up positively. I'm just saying, investors are probably going to decide to roll the dice on a complete staffing rebuild rather than try to wait for the existing corporate culture to adapt because they're going to get fomo. Arguably it's already happening.
davidcann 6mo ago
Is your team measuring how much of your code is being written with claude and comparing amongst the team, like what works best in your codebase? How are you learning from each other? I’m making a team version of my buildermark.dev open source project and trying to learn about how teams would like to use it.
- barnabee 6mo ago
  Different teams are using it in very different ways so it can be tough to compare meaningfully. Backends handling tens to hundreds of thousands of messages per second with extremely high correctness and resilience requirements are necessarily taking a different approach to less critical services that power various ancillary sites/pages or to front end web apps. That said there's a lot of very open discussion around tooling, "skills", MCP, etc., harnesses, and approaches and plenty of sharing and cross-pollination of techniques. It would be great to find ways to better quantify the actual value add from LLMs and from the various ways of using them, but our experience so far is that the landscape in terms of both model capability and tooling is shifting so fast that that's quite hard to do.
  - davidcann 6mo ago
    Thanks for the feedback. I agree that it’s changing very fast, which is why my thesis is that this tooling will be needed to help everyone on the team keep up.
jeremyjh 6mo ago
It sounds very similar to my shop. I have QA people and Product Managers using Claude to develop better integration and reporting tools in Python. Business users are vibe coding all kinds of tools shared as Claude Artifacts, the more ambitious ones are building single page app prototypes. We ported one prototype to Next.js and hosted on Vercel in a couple of days and then handed it back to them with a Devcontainer and Claude Code so they can iterate on it themselves; and we also developed all the security infrastructure, scaffolding, agent instructions & policy required to do this for low stakes apps in a responsible way. It hardly seems worth it to try to iterate on design when they can just build a completely functional prototype themselves in a few hours. We're building APIs for internal users in preference to UIs, because they can build the UIs themselves and get exactly what they need for their specific use cases and then share it with whoever wants it. We replaced an expensive, proprietary vendor product in a couple of weeks. I have no delusions about the scale or complexity limits of these projects. They can help with large, complex systems but mostly at the margins: help with impact analysis, production support, test cases, code review. We generate a lot of code too but we're not vibe coding a new system of record and review standards have actually increased because refactoring is so much cheaper. The fact is that ordinary businesses have a LOT of unmet demand for low stakes custom software. The ones that lean into this will not develop superpowers but I do think they will out-compete slow adopters and those companies will be forced to catch up in the next few years. I develop presentations now by dumping a bunch of context in a folder with a template and telling Claude Cowork what I want (it does much better than web version because of its python and shell tools and it can iterate, render, review, repeat until its excellent). The copy is quite good, I rewrite less than a third of it and the style and graphics are so much better than I could do myself in many hours. No one likes reading a bunch of vibe coded slop and cultural norms about this are still evolving; but on balance its worth it by far.
stasomatic 6mo ago
I am hobbyist playing around. Recently dropped CC (which gave me a sense of awe 2 months ago), but they realized GPUs need CapEx and I want to screw around with pi.dev on a budget. Then on to GH Copilot but couldn't understand their cost structure, ran out of quota half month in, now on Codex. I don't really see any difference for little stuff. I also have Antigravity through a personal Gmail account with access to Opus et al and I don't understand if I am paying for it or not. They don't have my CC so that's a breather. It's all romantic, but a bunch of devs are getting canned left and right, a slice of the population whose disposable income the economy depends on. It's too late to be a contrarian pundit, but what's been done besides uncovering some 0-days? The correction will be brutal, worse than the Industrial Revolution. Just the recent news about Meta cuts, SalesForce, Snap, Block, the list is long. Have you shipped anything commercially viable because of AI or are you/we just keeping up?
- fc417fc802 6mo ago
  > The correction will be brutal, worse than the Industrial Revolution. Has it occurred to you that there might not be a correction, and that the outcome would still be brutal, at least on par with the industrial revolution.
  - stasomatic 6mo ago
    Do you mean as in there will be no happy ending / reset and no another century of prosperity?
    - fc417fc802 6mo ago
      I mean as in living through the industrial revolution would have been wild. So whether we have an AI revolution or an AI bubble it's bound to be a roller coaster. And that's without accounting for the various wars (and resultant economic impacts) that are already in progress. A large part of what drove the meat grinder of WWI was (very approximately) the various actors repeatedly misjudging the overall situation and being overly enthusiastic to try out their shiny new weapons systems. If one or more superpowers decide to have a showdown the only thing that might minimize loss of life this time around is (ironically enough) the rise of autonomous weapons systems. Even in that case as we know from WWII the logical outcome is a decimated economy and manufacturing sector regardless of anything else that might happen.
ttul 6mo ago
This sounds like my office, but we're a bit more tilted toward Codex. I personally use Claude Cowork for drudge-admin work, GPT 5.5-Pro for several big research tasks daily, and the LLMs munge on each other's slop all day as I try my best to wrap my head around what has been produced and get it into our document repository -- all the while being conscious that the enormous volume of stuff I'm producing is a bit overwhelming for everyone. We are definitely reaching the point where you need an LLM to deal with the onslaught of LLM-generated content, even if the humans are being judicious about editing everything. We're all just cranking on an inhumanly massive amount of output and it's frankly scary.
- JambalayaJimbo 6mo ago
  Didn’t got 5.5 just come out lol. Am I just reading slop on this website?
  - ttul 6mo ago
    Yeah, it did just come out. I should have probably said "GPT-Pro" and left out the version :)
jwpapi 6mo ago
I think if you drop this all you will absolutely kill it.
- komali2 6mo ago
  I'm not sure. I have a buddy that's one of the better engineers I know personally, and he struggled to maintain an "AI Lent" for even a month. He found he just wasn't productive enough without it. He did a writeup: https://buduroiu.com/blog/ai-lent-end/ https://buduroiu.com/blog/ai-lent-end/
  - svieira 6mo ago
    > I delivered more work that I was less confident about, making me more miserable in the process Don't leave the kicker out of the story
    - komali2 6mo ago
      The kicker is he wasn't able to compete without the agents. IMO this is the natural end state of LLM fueled capitalism: products skating along the razor edge between "has value under capitalism" and "is a heap of garbage" until we suddenly realize there's nothing under our feet.
  - jwpapi 6mo ago
    His success measurement is PRs. The success measurement I mean is increased likelihood of company succeeding.
ojr 6mo ago
I am an early Gemini daily driver type engineer, feels like Node, Firefox, React and Tailwind all over again, Claude Sonnet is 10x more expensive, quick thought experiment do you think 10 Gemini prompts is needed to match the quality of one Claude Code prompt? The harness around Gemini is an issue but I built my own (in Rust)
am17an 6mo ago
Sounds exhausting. Are your revenue numbers up?
- eieie 6mo ago
  Incremental cash flows is what we should be observing - have to net out the costs of llm associated with the activity. Thats just one set of costs but a good starting point.
- camdenreslink 6mo ago
  I am also curious about the correlation between more PRs getting merged faster and actual business outcomes. My impression has always been it's more important the build the correct thing (what the customer needs/wants) rather than more stuff faster.
  - TeMPOraL 6mo ago
    > My impression has always been it's more important the build the correct thing (what the customer needs/wants) rather than more stuff faster. The process of learning what the customer needs/wants is a heavily iterative one, often involving throwing prototypes at them or betting at a solution, then course-correcting based on their reaction. Similarly, the process of building the correct thing is almost always an iterative approximation - correctness is something you discover and arrive at after research and prototypes and trying and getting it wrong. All of that benefits from any of its steps being done faster - but it's up to the org/team whether they translate this speedup to quality or velocity. For example, if AI lets you knock out prototypes and hypothesis-testing scripts much faster, you can choose whether to finish earlier (and start work on next thing sooner), or do more thorough research, test more hypothesis, and finish as normally, but with better result. (Well, at least theoretically. If you're under competitive pressure, the usual market dynamics will take the choice away, but that's another topic.)
    - dominotw 6mo ago
      no customers will accept "throwing prototypes at them". my time is not for QA-ing your product. why do you think restaurants rarely change their menus.
realusername 6mo ago
Personally at my place, there hasn't been a noticable velocity change since the adoption of Claude Code. I'd say it's even slightly worse as now you have junior frontend engineers making nonsense PRs in the backend. Mainn blockers are still product, legal, management ... which Claude code didn't help with.
croes 6mo ago
Jevon‘s paradox comes into play. https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox In the end only profit matters
dominotw 6mo ago
what have you guys built exactly?
- pwinnski 6mo ago
  I kept asking this question last year, especially after that initial METR report showing people believed themselves to be faster when they were slower. Then I decided to dive in feet-first for a few weeks so that nobody could say I hadn't tried all I could. At work, what I see happening is that tickets that would have lingered in a backlog "forever" are getting done. Ideas that would have come up in conversation but never been turned into scoped work is getting done, too. Some things are no faster at all, and some things are slower, mostly because the clankers can't be trusted and human understanding can't be sped up, or because input is needed from product team, etc. But the sorts of things that don't make it into release notes, and are never announced to customers, those are happening faster, and more of them are happening. We review server logs, create tickets for every error message we see, and chase them down, either fixing the cause or mitigating and downgrading the error message, or however is appropriate to the issue. This was already a practice, but it used to feel like we were falling farther behind every week, as the backlog of such tickets grew longer. Most low-priority stuff, since obviously we prioritized errors based on user impact, but now remediation is so fast that we've eliminated almost the entire backlog. It's the sort of things that if we were a mobile app, would be described as "improvement and bug fixes" generically. It's a lot of quality-of-life issues for use as backend devs. At home, I'm creating projects I don't intend for anyone outside my family to see. So far things I could theoretically have done myself, even related to things I've done myself before, but at a scale I wouldn't bother. Like a price-checker that tracks a watchlist of grocery items at nine local stores and notifies me in discord of sales on items and in categories I care about. It's a little agent posting to a discord channel that I can check before heading out for groceries. Or several projects related to my hobbies, automating the parts I don't enjoy so much to give me more time for the parts I do. My collection of a half-dozen python scripts and three cron jobs related to those hobbies has grown to just over 20 such scripts and 14 cron jobs. Plus some that are used by an agent as part of a skill, although still scripts I can call manually, because I'll go back to cron jobs for everything if the price of tokens rises a bit more. I was super-skeptical, and now I'm not. I think companies laying off employees are delusional or using LLMs as an excuse, but there is zero question in my mind that these things can be a huge boon to productivity for some categories of coding.
renegade-otter 6mo ago
Development velocity is faster, but the code quality hits take a while to manifest. Some places are more diligent, but most are not. We HATE reading other people's code, and we only have so much focus capacity per day to review all the shit these clunkers spew out. Over time, the errors induced by Looks Good To Me code reviews compound.
kaiokendev 6mo ago
> Every time someone has any idea it's accompanied by a multi page "Clauded" memo explaining why it's a great idea and what exactly should be done (about 20% of which is useful). we're in the same boat, and currently trying to fix that 20% problem because it's the biggest hindrance to shipping things quickly there is a ton of learned ceremony that we have to undue gracefully because it's extremely tempting to vibe code a problem spec as opposed to just... talking to users directly and understanding what the actual problem is

mullingitover 6mo ago

> - Development velocity is very noticeably much higher across the board It's an absolute tornado of PRs these days. Everyone making the most of these tools is effectively an engineering team lead.

MrDarcy 6mo ago
The CTO/VP of engineering role down is now singularly focused on keeping agents fed with a backlog of Linear issues. This is the new normal.
- aenis 6mo ago
  As a CTO I can say that this is not my experience. My experience these days is fighting corporate bureaucracy and inertia to make sure we reap the benefits of faster coding. Feeding agents with work is not a problem. Building teams that use those tools effectively is the problem. (Say, shall we merge product and engineering teams? Do we start getting rid of people who refuse to use AI? What do we do with pentests? How do we strengthen the tools that do code analysis and weed out lazy devs who can now more easily pretend to be invested in their work? Stuff like this keeps me busy.
  - mullingitover 6mo ago
    > Do we start getting rid of people who refuse to use AI? I don't even think the bigger companies are going to waste time on figuring out how to retrain, they're just going to do industrial scale layoffs and then rebuild from the ground up with people who won't get past interviews without demonstrating hard skills in this area. There is a shocking gap growing right now, it's a Wile E. Coyote not realizing he already walked off the cliff type of situation for a lot of people.
    - eieie 6mo ago
      Lol people like you operate in a local maximum. Ultimately the shareholders want to see the money. They dont give a crap about what you think or what the poster above thinks - you're both accountable to the shareholders who do not employ you for fun. They employ you for the sole purpose of making them wealthier. All this incremental spend on tokens shows up in the financials positively or it doesn't.
      - mullingitover 6mo ago
        > Ultimately the shareholders want to see the money. Seems like we're saying the same thing? > All this incremental spend on tokens shows up in the financials positively or it doesn't. Right, and we're talking about the staff failing to spend the incremental tokens at all, thus failing to discover whether or not they'll show up positively. I'm just saying, investors are probably going to decide to roll the dice on a complete staffing rebuild rather than try to wait for the existing corporate culture to adapt because they're going to get fomo. Arguably it's already happening.

davidcann 6mo ago

Is your team measuring how much of your code is being written with claude and comparing amongst the team, like what works best in your codebase? How are you learning from each other? I’m making a team version of my buildermark.dev open source project and trying to learn about how teams would like to use it.

barnabee 6mo ago
Different teams are using it in very different ways so it can be tough to compare meaningfully. Backends handling tens to hundreds of thousands of messages per second with extremely high correctness and resilience requirements are necessarily taking a different approach to less critical services that power various ancillary sites/pages or to front end web apps. That said there's a lot of very open discussion around tooling, "skills", MCP, etc., harnesses, and approaches and plenty of sharing and cross-pollination of techniques. It would be great to find ways to better quantify the actual value add from LLMs and from the various ways of using them, but our experience so far is that the landscape in terms of both model capability and tooling is shifting so fast that that's quite hard to do.
- davidcann 6mo ago
  Thanks for the feedback. I agree that it’s changing very fast, which is why my thesis is that this tooling will be needed to help everyone on the team keep up.

jeremyjh 6mo ago

It sounds very similar to my shop. I have QA people and Product Managers using Claude to develop better integration and reporting tools in Python. Business users are vibe coding all kinds of tools shared as Claude Artifacts, the more ambitious ones are building single page app prototypes. We ported one prototype to Next.js and hosted on Vercel in a couple of days and then handed it back to them with a Devcontainer and Claude Code so they can iterate on it themselves; and we also developed all the security infrastructure, scaffolding, agent instructions & policy required to do this for low stakes apps in a responsible way. It hardly seems worth it to try to iterate on design when they can just build a completely functional prototype themselves in a few hours. We're building APIs for internal users in preference to UIs, because they can build the UIs themselves and get exactly what they need for their specific use cases and then share it with whoever wants it. We replaced an expensive, proprietary vendor product in a couple of weeks. I have no delusions about the scale or complexity limits of these projects. They can help with large, complex systems but mostly at the margins: help with impact analysis, production support, test cases, code review. We generate a lot of code too but we're not vibe coding a new system of record and review standards have actually increased because refactoring is so much cheaper. The fact is that ordinary businesses have a LOT of unmet demand for low stakes custom software. The ones that lean into this will not develop superpowers but I do think they will out-compete slow adopters and those companies will be forced to catch up in the next few years. I develop presentations now by dumping a bunch of context in a folder with a template and telling Claude Cowork what I want (it does much better than web version because of its python and shell tools and it can iterate, render, review, repeat until its excellent). The copy is quite good, I rewrite less than a third of it and the style and graphics are so much better than I could do myself in many hours. No one likes reading a bunch of vibe coded slop and cultural norms about this are still evolving; but on balance its worth it by far.

stasomatic 6mo ago

I am hobbyist playing around. Recently dropped CC (which gave me a sense of awe 2 months ago), but they realized GPUs need CapEx and I want to screw around with pi.dev on a budget. Then on to GH Copilot but couldn't understand their cost structure, ran out of quota half month in, now on Codex. I don't really see any difference for little stuff. I also have Antigravity through a personal Gmail account with access to Opus et al and I don't understand if I am paying for it or not. They don't have my CC so that's a breather. It's all romantic, but a bunch of devs are getting canned left and right, a slice of the population whose disposable income the economy depends on. It's too late to be a contrarian pundit, but what's been done besides uncovering some 0-days? The correction will be brutal, worse than the Industrial Revolution. Just the recent news about Meta cuts, SalesForce, Snap, Block, the list is long. Have you shipped anything commercially viable because of AI or are you/we just keeping up?

fc417fc802 6mo ago
> The correction will be brutal, worse than the Industrial Revolution. Has it occurred to you that there might not be a correction, and that the outcome would still be brutal, at least on par with the industrial revolution.
- stasomatic 6mo ago
  Do you mean as in there will be no happy ending / reset and no another century of prosperity?
  - fc417fc802 6mo ago
    I mean as in living through the industrial revolution would have been wild. So whether we have an AI revolution or an AI bubble it's bound to be a roller coaster. And that's without accounting for the various wars (and resultant economic impacts) that are already in progress. A large part of what drove the meat grinder of WWI was (very approximately) the various actors repeatedly misjudging the overall situation and being overly enthusiastic to try out their shiny new weapons systems. If one or more superpowers decide to have a showdown the only thing that might minimize loss of life this time around is (ironically enough) the rise of autonomous weapons systems. Even in that case as we know from WWII the logical outcome is a decimated economy and manufacturing sector regardless of anything else that might happen.

ttul 6mo ago

This sounds like my office, but we're a bit more tilted toward Codex. I personally use Claude Cowork for drudge-admin work, GPT 5.5-Pro for several big research tasks daily, and the LLMs munge on each other's slop all day as I try my best to wrap my head around what has been produced and get it into our document repository -- all the while being conscious that the enormous volume of stuff I'm producing is a bit overwhelming for everyone. We are definitely reaching the point where you need an LLM to deal with the onslaught of LLM-generated content, even if the humans are being judicious about editing everything. We're all just cranking on an inhumanly massive amount of output and it's frankly scary.

JambalayaJimbo 6mo ago
Didn’t got 5.5 just come out lol. Am I just reading slop on this website?
- ttul 6mo ago
  Yeah, it did just come out. I should have probably said "GPT-Pro" and left out the version :)

jwpapi 6mo ago

I think if you drop this all you will absolutely kill it.

komali2 6mo ago
I'm not sure. I have a buddy that's one of the better engineers I know personally, and he struggled to maintain an "AI Lent" for even a month. He found he just wasn't productive enough without it. He did a writeup: https://buduroiu.com/blog/ai-lent-end/ https://buduroiu.com/blog/ai-lent-end/
- svieira 6mo ago
  > I delivered more work that I was less confident about, making me more miserable in the process Don't leave the kicker out of the story
  - komali2 6mo ago
    The kicker is he wasn't able to compete without the agents. IMO this is the natural end state of LLM fueled capitalism: products skating along the razor edge between "has value under capitalism" and "is a heap of garbage" until we suddenly realize there's nothing under our feet.
- jwpapi 6mo ago
  His success measurement is PRs. The success measurement I mean is increased likelihood of company succeeding.

ojr 6mo ago

I am an early Gemini daily driver type engineer, feels like Node, Firefox, React and Tailwind all over again, Claude Sonnet is 10x more expensive, quick thought experiment do you think 10 Gemini prompts is needed to match the quality of one Claude Code prompt? The harness around Gemini is an issue but I built my own (in Rust)

am17an 6mo ago

Sounds exhausting. Are your revenue numbers up?

eieie 6mo ago
Incremental cash flows is what we should be observing - have to net out the costs of llm associated with the activity. Thats just one set of costs but a good starting point.
camdenreslink 6mo ago
I am also curious about the correlation between more PRs getting merged faster and actual business outcomes. My impression has always been it's more important the build the correct thing (what the customer needs/wants) rather than more stuff faster.
- TeMPOraL 6mo ago
  > My impression has always been it's more important the build the correct thing (what the customer needs/wants) rather than more stuff faster. The process of learning what the customer needs/wants is a heavily iterative one, often involving throwing prototypes at them or betting at a solution, then course-correcting based on their reaction. Similarly, the process of building the correct thing is almost always an iterative approximation - correctness is something you discover and arrive at after research and prototypes and trying and getting it wrong. All of that benefits from any of its steps being done faster - but it's up to the org/team whether they translate this speedup to quality or velocity. For example, if AI lets you knock out prototypes and hypothesis-testing scripts much faster, you can choose whether to finish earlier (and start work on next thing sooner), or do more thorough research, test more hypothesis, and finish as normally, but with better result. (Well, at least theoretically. If you're under competitive pressure, the usual market dynamics will take the choice away, but that's another topic.)
  - dominotw 6mo ago
    no customers will accept "throwing prototypes at them". my time is not for QA-ing your product. why do you think restaurants rarely change their menus.

realusername 6mo ago

Personally at my place, there hasn't been a noticable velocity change since the adoption of Claude Code. I'd say it's even slightly worse as now you have junior frontend engineers making nonsense PRs in the backend. Mainn blockers are still product, legal, management ... which Claude code didn't help with.

croes 6mo ago

Jevon‘s paradox comes into play. https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox In the end only profit matters

dominotw 6mo ago

what have you guys built exactly?

pwinnski 6mo ago
I kept asking this question last year, especially after that initial METR report showing people believed themselves to be faster when they were slower. Then I decided to dive in feet-first for a few weeks so that nobody could say I hadn't tried all I could. At work, what I see happening is that tickets that would have lingered in a backlog "forever" are getting done. Ideas that would have come up in conversation but never been turned into scoped work is getting done, too. Some things are no faster at all, and some things are slower, mostly because the clankers can't be trusted and human understanding can't be sped up, or because input is needed from product team, etc. But the sorts of things that don't make it into release notes, and are never announced to customers, those are happening faster, and more of them are happening. We review server logs, create tickets for every error message we see, and chase them down, either fixing the cause or mitigating and downgrading the error message, or however is appropriate to the issue. This was already a practice, but it used to feel like we were falling farther behind every week, as the backlog of such tickets grew longer. Most low-priority stuff, since obviously we prioritized errors based on user impact, but now remediation is so fast that we've eliminated almost the entire backlog. It's the sort of things that if we were a mobile app, would be described as "improvement and bug fixes" generically. It's a lot of quality-of-life issues for use as backend devs. At home, I'm creating projects I don't intend for anyone outside my family to see. So far things I could theoretically have done myself, even related to things I've done myself before, but at a scale I wouldn't bother. Like a price-checker that tracks a watchlist of grocery items at nine local stores and notifies me in discord of sales on items and in categories I care about. It's a little agent posting to a discord channel that I can check before heading out for groceries. Or several projects related to my hobbies, automating the parts I don't enjoy so much to give me more time for the parts I do. My collection of a half-dozen python scripts and three cron jobs related to those hobbies has grown to just over 20 such scripts and 14 cron jobs. Plus some that are used by an agent as part of a skill, although still scripts I can call manually, because I'll go back to cron jobs for everything if the price of tokens rises a bit more. I was super-skeptical, and now I'm not. I think companies laying off employees are delusional or using LLMs as an excuse, but there is zero question in my mind that these things can be a huge boon to productivity for some categories of coding.

renegade-otter 6mo ago

Development velocity is faster, but the code quality hits take a while to manifest. Some places are more diligent, but most are not. We HATE reading other people's code, and we only have so much focus capacity per day to review all the shit these clunkers spew out. Over time, the errors induced by Looks Good To Me code reviews compound.

kaiokendev 6mo ago

> Every time someone has any idea it's accompanied by a multi page "Clauded" memo explaining why it's a great idea and what exactly should be done (about 20% of which is useful). we're in the same boat, and currently trying to fix that 20% problem because it's the biggest hindrance to shipping things quickly there is a ton of learned ceremony that we have to undue gracefully because it's extremely tempting to vibe code a problem spec as opposed to just... talking to users directly and understanding what the actual problem is