The first half of your sentence sounds like really swift and effective persuasion, to me.

E.G. over time we’d gained two client-side caches of related server state. This started out as two different parts of the same model, because we couldn’t get all the data we needed from one microservice and had to merge in the client. Over time, more and more features used both caches for different aspects of related processes. At some point one of the microservices changed so as to return all the data in one call. The update to consume that kept both caches, adding code to sync them, because so many parts of the code were using one as a fallback for the other, so they both looked “necessary”. Because they were separate, and “live” sometimes they’d go out of sync after the initial load. Worse: the consumers alternated about which cache was treated as the fallback, making it very hard to see that either might be redundant. Eventually I noticed they were filled by the response to a single call. We all know paying back tech debt never gets prioritised, so I rolled the payback into two feature tasks, and just took longer about them.

My employer expects we use LLMs and provides some budget, but it’s not enough to use even Open4.7 or GLM-5.2 on every task. I do the bulk of my work with Composer 2.5. It’s quite good for “going forward” on smallish tasks and it’s written most of my code this year. It’s possible smarter models would spot these refactorinh opportunities and action them proir to building features or fixing bugs. But I wouldn’t know because I can’t afford it. I’ve never seen even a 4.8 era model spot a refactor and plan to do it prior to a “new build”.

I’m pleased I’ve spotted these trends and started to build the habit of (telling the agent to)“refactor to make the change easier”, but my percieved productivity will go down and I risk the ire of my leaders.

AIs automate the copying (and to some degree the derrivation mode too). They do it 1000s of times a day. The capital owners who provide this as a service are doing one of these two: - either claiming the IP isn’t valuable in the first place and charging only for the machinery they’re providing - or claiming the fees they charge contribute to the costs incurred with acquiring training data, but not sharing that with the training data creators in a royalties/licence-like manner (so, I’m sayung they’re devaluing the source material but not to zero, and resisting reasonable profit share or collaboration)

However, I agree it might be less performant, and it's a certain kind of thinking that isn't quickly grokked (and doesn't have to be). I deliberately tried to write my story about the interview so as to make it sound like there's positives and negatives to both positions expressed. _I_ have a preference for that functional style, but I know it's not for everyone. That's totally fine.

I really like taking the implementation away from the call site, so that the call site reads

    const myNewValue = data.reduce(doSomethingMagic); 

I failed a job interview once by using reduce() in a coding test. The reviewer didn't understand why I hadn't used a loop. Loops are easier, for sure, but they sprawl and are open to hacking. They can bring in state from outside the loop. They make the call site long (you always have to read the implementation to learn that you don't need to read it). The same interviewer actively liked to have loop bodies modify the loop conditions (e.g. by taking items out of the source array and decrementing the end condition, so the loop would end earlier). That's the kind of "clever" I find unpredictable and hard to think about. Probably a good thing he rejected me.

I’d previously understood the relationship to be that the document could remain unchanged, whilst the style (including visual structure/layout) changed. The simplest canonical example is that you can change the font, and all the words and meaning remain unchanged.

> You see this with localization. You might need to change spacing or padding or breakpoints to accomodate different languages (text being different length in different languages).

This is a really intereting case. Strictly I’d say it was a different document, if the language has changed. Really good translations change idiom, which can change meaning, and words, at the level of ohraes, although the intent would be preserved.

But I’m nit-picking, being contrarian, or exploring the edges of your comment.

Today, many web documents are app GUIs. Each field is essentially the same “thing” regardless the languge of its label. And in that sense, these are the same document, and your point holds.

I still think that if you can keep the markup as minimal as possible (reduce the div nesting to just what’s require to mark up logical sections of the content), then you could make a good stab at Zen-gardening your design. It’s very hard to do, however.

(I accept, I could book a demo at an Apple Store...)

Only by sexists.

I asked a second session to try interpreting the message, claiming I’d transcribed it from some random source. It did a fairly good job, but IIRC needed a couple of attempts and maybe more than one chunk of text.

So, I find it very easy to believe a group of collaborating agents could compose a cipher hidden in plain sight.

Anecdata: I’d be more likely to use the services of a company with a good, old-style site than a bad, new style site. Things like pop-overs, text that animates in as you scroll, banner images that take up most of the “abive the fold” are all red flags for me.

Oh, and the most common one: “Read more”.

A modern site that avoids all those can be great. But those are rare, IMO.

It looks like a well crafted UI, with care and attention to detail. The kind of thing that takes coordination. Scrum can help with that.

The grandparent poster seemed to be claiming the opposite: that scrum makes such things harder to achieve. That doesn’t match my experience. I think you can make a polished product, or a mess, using any of a variety of coordination technuqies. If anything, the planning technique is orthogonal to the cohesion of the product (although IMO if you do Scrum well, you’ll probably find it easier to coordinate towards a high cohesion product). But Scrum (or any well run system) is not the only factor. At a minimum you need a team who want a high cohesion product; you need some people who can help steer production towards a high-cohesion product; you need to have people on the team willing to have their opinions challenged from time to time; and, if you’ll indulge a little axe-grinding, you need the younger team members to trust the more experienced ones.

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

https://en.wikipedia.org/wiki/Erin_Brockovich#Pacific_Gas_&_...

https://en.wikipedia.org/wiki/Exposure_(Bilott_book)

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

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

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

https://en.wikipedia.org/wiki/Grimshaw_v._Ford_Motor_Co.

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

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

So putting money in my savings account is gambling, but investing in businesses is not.

I suspect I misunderstand your point completely.

Also, AFAIK, this mirrors how command line utils would work.