[barnabee]

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.

[stasomatic]

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]

> 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.

[SlinkyOnStairs]

It won't get that far.

It's physically impossible to build out the datacenters required for the "AI is actually good and we have mass layoffs" scenario. This Anthropic investment is spurred on because they've already hit a brick wall with capacity.

$40B goes a long way, but not for datacenters where nearly every single component and service is now backordered. Even if you could build the DC, the power connection won't be there.

The current oil crisis just makes all of that even worse.

[fc417fc802]

Doesn't that just draw out the AI revolution by a few years? I don't see why it would stop anything though.

Imagine a scenario where someone claimed that it was physically impossible to replace all the buggies with automobiles because everything was backordered and there were labor shortages. Surely the replacement still happens eventually though?

[SlinkyOnStairs]

A drawn out long change simply doesn't have the major societal upset that imminent mass-unemployment has.

With how much scale AI datacenters want and how the Trump administration has made supply problems significantly worse, we'd be talking decades, plural.

[fc417fc802]

I don't think lowering the rate a bit is going to be sufficient to avoid major upsets. If (arbitrary example) every software developer were forced to switch jobs over a 10 year period that would still be an extremely disruptive sequence of events. And I don't think there's any scenario in which software developers are widely impacted but other industries somehow aren't.

Digitization was already fairly disruptive and that involved much smaller changes than what we appear to be facing while also taking place over something like 30 years or more.

[fallat]

We pretty much already had the layoffs, at least that's my perception.

The next level of layoffs is probably still 25 years out.

[SlinkyOnStairs]

There's layoffs, certainly.

But all the economic indicators suggest those are "bad economy" layoffs dressed up as "AI" layoffs to keep the shareholders happy.

[bitmasher9]

The real “AI layoffs” are all the people that are PIPed because their colleagues are better at leveraging AI.

[embedding-shape]

> The next level of layoffs is probably still 25 years out.

Hasn't even been 25 years years since the previous layoffs before the current ones.

[stasomatic]

Do you mean as in there will be no happy ending / reset and no another century of prosperity?

[fc417fc802]

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.

[Aeolun]

> minimize loss of life this time around is (ironically enough) the rise of autonomous weapons systems

I think that just means the relative civilian loss of life will increase once again.

[fc417fc802]

What strategic merit is there in targeting civilians or life critical infrastructure in a fully automated battlebot scenario? Perhaps it's naive but I would expect stockpiles, datacenters, and any key infrastructure on which the local semiconductor fabrication depends to be the primary targets.

[rhubarbtree]

Bubble or revolution - not a dichotomy.

Bubbles like the AI bubble are a game theoretic outcome of a revolution. Many players invest heavily to avoid losing, but as a whole the market over invests. This leads to a bubble.

[chpatrick]

Imagine you're a typesetter and they just invented computerized printing.

[Spivak]

These kinds of comments are so confusing to me, is the work you do day to day really so trivial that you can be wholesale replaced by an LLM?

[chpatrick]

90% of the actual code writing? Yes. The actually valuable part is coming up with the ideas for what to do.

There isn't going to be a great reset where everyone goes back to coding by hand any more than we're going back to typesetting by hand.

[fc417fc802]

We're not talking about the LLMs of today but whatever shows up 2 years from now and then again 2 years after that. Don't look at the present state of things but instead project the trend line.

[jameshart]

There has always been a gap between the experience of solo/small shop developers, vs. developers who work in teams in a large corporate environment. But thanks to open source, we have for the past twenty years at least mostly all been using the same tools.

But right now, the difference in developer experience between a dev on a team at a business which has corporate copilot or Claude licenses and bosses encouraging them to maximize token usage, vs a solo dev experimenting once every few months with a consumer grade chat model is vast.

[eieie]

Let’s take an extreme example.

Meta seemingly has a constant stream of product managers. If llm’s really augment the productivity of engineers, why isn’t meta launching lots more stuff? I mean there’s no harm in at least launching one new thing.

What are all those people doing with the so called productivity enhancements?

What I’m calling into question is how much does generating more code matter if the bottle neck is creativity/imagination for projects?

The only thing I’ve seen is a really crummy meta AI thing implemented within WhatsApp.

[bushbaba]

It’s allowed a sludge of internal tools to spin up, and more bloat. The ability to sand bag and over build these tools has gotten 2-10x worse.

Only solution I can think of is to drastically cut headcount so productivity is back to prior levels, and profitability is raised. Big Tech is mostly market constrained with not much room to grow beyond the market itself growing.

As for startups, seems like AI tools have drastically reduced their time to market and accelerated their growth curves.

[eieie]

Im convinced the most scarce skill on the planet is the ability to a) envision something that needs to exist in the world b) explain how the thing creates value from a financial perspective.

Most people tend to think they know what they are talking about (e.g. surface level understanding of how to think economically) and end up making basket-case decisions - only realising it months later. By that point they will fail to admit defeat and keep going on.

"As for startups, seems like AI tools have drastically reduced their time to market and accelerated their growth curves."

You mean like openclaw? lol

[aenis]

In a word, bottlenecks moved.

What I see in my backyard: coding now takes significantly less time, but its just coding. Before one gets to building there are squabbles between business and product people. Testing takes just as much as it used to. Since nice to haves are easy to add and product people begin to take it for granted, the product cycles don't get shorter.

Give it time. Right now its just coding, but procedural AI will come after product development, architecture, and then whatever is left of management.

[eieie]

Absolute delusion.

The best people can not only envision products but also possess great judgement without needing data. For AI to even come close it would need an insane amount of data that is nuanced and subtle - by the the time the AI has obtained all the necessary data and made sense of it the human is long gone working on something else.

[stasomatic]

But these people will age out and juniors do not get hired. “Good judgment comes from experience, and experience comes from bad judgment.” and all that.

Is LLM going to invent its own languages that no average programmer will understand? As in "I don't need your C++ human, I will rewrite your fart app in ClaudASM and you will like it". These are naive questions, but I can't visualize how all of this will unfold.

[elliotec]

Forgive my ignorance, but what exactly is the vast difference? Who's doing more of what, or whatever you're implying? And how do you quantify this?

[aenis]

The people who use AI to the maximum learn more.

A neutral hobbyist on a $20 budget will build something and immediately bump into quotas. Its not going to be an enjoyable experience.

A negatively predisposed pro who only dabbles in AI gets to the first disappointment, smiles, and thinks "yeah, about what i expected" and quits.

To learn those new tools one needs to not be stingy. Invest as much as needed into tokens, subscriptions, and maybe most importantly invest the time. Spend time building various things. Try out various models not just for coding, but as part of apps being built. For bonus points, meaningfully experiment with local models. I try to avoid discussions with sceptics who have not put at least a few months of effort into learning those tools. It's like discussing driving with my mother in law, who spent maybe 20hrs behind the wheel through her whole life (and is very, very opinionated!).

[LtWorf]

And it's not a waste of money because?

[aenis]

You'd have learned something new. Useful, not useful, thorough understanding of a new thing is rewarding.

Also, its not primarily about money - the real investment here is time.

[jameshart]

The difference is (if you'll forgive me recruiting a couple of straw men for the purpose of illustrating the spectrum we are talking about here):

Hobbyist solo dev, counting tokens, hitting quotas, trying things on little projects, giving up and not seeing what the fuss is about.

vs

Corporate developer, increasingly held accountable by their boss for hitting metrics for token usage; being handed every new model as soon as it comes out; working with the tools every day on code changes that impact other developers on other teams all of whom have access to those same tools.

[elliotec]

Okay, so just to be clear you're not commenting on productivity? Or what does "changes that impact" mean?

I might be missing a lot of self-evident assumptions here but I feel like I'm still missing so much context and have no idea what this difference is actually describing.

[jameshart]

If you have some objective measure of productivity in mind, feel free to share it, but no that's not what I'm commenting on.

I'm talking more about why threads like this seem to be full of people saying 'this has completely changed how corporate development works' and other people saying 'I tried it a few times and I don't get the hype'

[bluGill]

Developers being let go is about the economy. Every time we see a slowdown people are let go and we always blame the fad but it's the economy not whatever.

[kaiokendev]

> 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]

> - 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]

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]

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.

[lobsterthief]

As a CTO this has been my experience as well. I would add in every non-technical C-suite member aiming to use AI as some magic lever to avoid prioritizing projects or engaging in real critical thinking. Too many people are offloading their cognitive decisionmaking to some magic box, thinking it has all the answers, because its output appears magical and complete.

After 25 years in programming I think I’ll finally start that farm ;)

[mullingitover]

> 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]

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]

> 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.

[am17an]

Sounds exhausting. Are your revenue numbers up?

[camdenreslink]

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]

> 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]

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.

[joshuacc]

You have a specific idea of customer in mind. Likely different than the gp’s. Many types of customers are quite happy to have prototypes thrown at them. Sometimes it’s even contractually required in agency work.

[eueew]

Is it just me or is this whole mania exposing those people who thought they were great ‘thinkers’? The takes I see are so utterly flawed it’s ironic - people refer to llm’s as hallucinating when the real halluncinations are from people cosplaying the role of management/investors when they have never done said role professionally in their life.

[aenis]

For sure, but these days product management mistakes can be more easily rectified. Before that, if we invested 4 months in building something that did not land, we'd be quite reluctant to jettison this and start fresh. Egos, career considerations, sunk cost, etc. I think I will soon be able to say "not any more", since doing a U turn can be cheaper than pretending the bad choice is the best choice. "Oops, lets redo this" vs. 6 months of executive squabbling about whose fault it is that we wasted $3M in development costs on something that clearly does not perform.

Also, give it time. Real adoption in boring companies started Q1. Q2 is, I think, this settling in and people learning how to do their work and manage their responsibilities. Q3/Q4 will be the time when I expect to start seeing higher velocities across all IT-adjacent products I use.

[barnabee]

Iteration speed is far more important than the volume of features delivered, though we are tackling aspirational features that would previously have been considered too complex or niche, too.

[mewpmewp2]

This with the ability to research, iterate on prototypes, in my opinion allows to determine the right thing quicker as well. Of course right now the value is largely intuition based, there may be some immediate revenue/profit, but revenue/profit will take time to follow, so in a way it is a speculative intuition based bet. Financial gains will take time to follow, so for a period of time it will be "trust me bro" for at least some cases, but I suppose future will show, since the intuition seems so strong about it. You can't have good data about an emerging tech like that.

[camdenreslink]

I question the premise that faster iteration on prototypes leads to better revenue or business outcomes.

[fragmede]

Isn't that trivially true? Scenario 1) Spend $10,000 to make one prototype. You get one shot, so you prepare and do as much pre-work as humanly possible, but because you only get one shot, you forgot the ask the question that in Hobbs sight was obvious. Scenario 2) prototypes cost $1,000 so you get multiple shots. So you don't do as much pre-work, throw a half dozen things at the wall. One of them sticks! It really resonates with customers. You iterate a few more times, and when it's finally on the market, you have a successful business.

The difference is all that pre-work. The problem with that is some things are only obvious after you've built one and it doesn't fit just right for some reason. That reason is impossibly harder to just reason about and figure out vs iterating where possible. For software things that's easier. For hardware, we have stories like the palm pilot engineer having a wooden block with them for a week before deciding on the form factor for it. Such pre-work is valuable, but if the cost of prototypes is way down, you can afford to iterate instead of trying to psychically predict everything up front. Of course that doesn't work for eg trips to the Moon, but most busineeses aren't doing that.

[camdenreslink]

The problem is in validating the prototype. Whether the users are consumers or enterprises or internal stakeholders, they aren’t going to try 10 different prototypes. They will try one or two.

Most business software isn’t complicated to implement (i.e. it doesn’t require multiple prototypes to determine which technical approach is best). Usually for most apps you approximately know the technical implementation. What requires taste, experience, or whatever you want to call it, is the user experience and if your software actually solves a real problem. You can’t really just churn on prototypes to solve that. You will lose the patience of your user base.

[barnabee]

Yes, it is trivially true much of the time.

Even so-called UX and product experts get stuff wrong all the time. Going from idea to prototype to feedback in hours or days rather than days or weeks feels like a superpower, at least in the very customer facing parts of what we do.

[groundzeros2015]

Did CAD make engineers better? certain products are only possible because of CAD but the pen and paper guys weren’t obviously less efficient, and I personally think they were very efficient.

When prototypes are harder to build you focus on answering the biggest questions. I feel like you spend more time iterating on details in CAD, even when the larger idea is invalid.

[eueew]

Agreed it’s far more complex than that.

But people who have only wrote software their entire life wouldn’t know that would they?

It’s like the econ prof’s who theorise about the theory of the firm but have never done it themselves.

[eieie]

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.

[xnx]

Reducing costs is also a business benefit.

[am17an]

The cost being reduced is the cost of your labour. Tokens are only getting more expensive.

[xnx]

Did you mean less expensive?

https://pricepertoken.com/trends#frontier-pricing

[am17an]

No I mean more expensive, i.e. you're consuming vastly more tokens.

[barnabee]

It’s no more exhausting than the alternative. It feels good being able to build more and experiment more.

The biggest downside is the feeling that people sometimes turn their brain off and aren’t even doing basic checks on some of the slop their LLMs produce.

[jeremyjh]

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.

[realusername]

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.

[davidcann]

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]

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]

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.

[croes]

Jevon‘s paradox comes into play.

https://en.wikipedia.org/wiki/Jevons_paradox

In the end only profit matters

[ojr]

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)

[jwpapi]

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

[komali2]

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/

[svieira]

> 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]

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]

His success measurement is PRs. The success measurement I mean is increased likelihood of company succeeding.

[ttul]

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]

Didn’t got 5.5 just come out lol. Am I just reading slop on this website?

[ttul]

Yeah, it did just come out. I should have probably said "GPT-Pro" and left out the version :)

[dominotw]

what have you guys built exactly?

[barnabee]

Everything from complex backend logic and processing to new user facing festivals, ops and infra tools, analytical apps, etc.

A lot of engineers now describe the problem, discuss the outline of the solution with the LLM, and then get it to write and test most of it ahead of their review. They tell me it usually takes the same approach they would anyway and even when it doesn’t, it’s often faster to explain what’s wrong and give the LLM another try.

Very little (and even then, only simple internal tools) gets written without a human owning the code and reviewing it thoroughly, but even with that overhead the productivity boost is impressive.

[pwinnski]

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.

[LittleBox]

I went through a similar journey. That and having read all the other experienced engineers’ anecdotes I think the current consensus is that it can boost productivity and does so for a lot of people but that vibe coding still remains unviable in a lot of situations.

[renegade-otter]

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.