the_other

The last couple of weeks, I’ve got rigorous about making the agent refactor old code. We’ve removed, moved, consolidated, reordered loads of cruft. It has made the code much tidier and reduced the chance that the next feature will build on top of cruft.

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.

That’s an admission of guilt by the police, right there. If you have nothing to hide… etc.

It matters so that average people have a chance to own their means of production, and that the current hardware-grab by entrenched capital doesn't get to charge such high rent.

When a human learns, they carry that forward into their future ventures. They might use their learning to recreate the original work and profit from it without attribution. In the West we view that badly and have legislation to protect from some abuses. But the same person might later collaborate with the original author, or make a derrivaive work that improves on the original (a la most science).

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)

Reduce definitely does not reduce character count. It's the loop-hacking that does that.

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.

(JS/TS is my main language) I love reduce()! It's a hammer/nail method for me. Everything looks like a problem solvable by reduce. (I'm often wrong on that, but I quite enjoy learning why by trying).

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

    const myNewValue = data.reduce(doSomethingMagic); 

(and then `doSomethingMagic` is defined somewhere else). So simple.

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.

> The document and the style depend on eachother.

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'm partially sighted. I've yet to see an AVP demo that made me want to try one out as an access tool. In fact, everything I've seen so far suggested it would be a hinderance. Can you suggest how it could help? What am I missing?

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

> But now "female led" has entered the conversation as something to recognize a scam by.

Only by sexists.

I once had much fun prompting Claude to generate messages in an invented language that might carry a chance of being interpreted by another chat session. It (allegedly) made up some mess of characters claiming the message explained, in a loose way, what was happening (invented language, an attempt to communicate, but communicated very abstractly, almost like equations).

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.

> but old website was minor liability in its datedness potentially putting off prospective patients.

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.

Quite the opposite.

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.

Eh? It looks exactly like it was put through a scrum pipeline.

> Nothing is ideal

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

> Not really. The question is are you working for your money or are you hoping the money will provide free rent for you. If the latter, you're gambling.

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

I suspect I misunderstand your point completely.

Just an anecdata: I really dislike the Cursor IDE's session/worktree handling, but my company only provide Cursor licences. So I'm using herdr, cursor cli ("agent"), a custom workflow skill that reads a manifest of the repos I work with + the setup commands they need.

If it's "people all the way down", why do companies pay so much less tax?

One advantage to leaving the configs around is that the next time you install the app, yiu get it set up just the way you had it before.

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

> All else being equal, you want to produce more with less labor and other inputs.

I'm not sure how to work with the "all else being equal" part. I suspect it's a way to get out of dealing with the truth of the situation, but feel free to expand on it.

But.. to the main point: "you want to produce more with less labor and other inputs" <- the owner of the business does, yes. But unemployment statistics and in general "labour" wants the opposite.

Let's take this to an extreme. Take all the business owners in the land and make them so efficient they only need employ themselves. "Productivity" remains the same, but now the bulk of the inhabitants of the land are unemployed, and can't buy the "products". So now the owners make no money and go bankrupt. And no-one has work. And there's no productivity.

I think what "you" really want (and by "you" I mean "we") is for business owners to make only the slightest margin of profit possible (after paying themselves) to keep their businesses running and to employ as many people as possible, who all get paid as close as possible to the owner; and for any left-over to be reinvested in new businesses with the same approach to paying staff. That way more people have a job, more people are "productive" and more people can buy the stuff made by the companies.

Sure, this is a ridiculous extreme, but it makes more sense to me than "you want to produce more with less labor and other inputs". I am curious though: is there an equally impractical and extreme story that works to bolster your argument, to help me see the pattern more clearly?

If you ban the latter, the former will proliferate in secret until it becomes the dominant culture.

It's both "the entire nation's infrastructure." and not that.

What I mean is... many cases are individual: the ramp for that library; the door knobs/handles in that office; the floor indicators in this lift/elevator; the audio announcements (or lack of) on the busses/trains; the small print on contracts; live subtitling at the theatre; the checkout button on this web site; the checkout button on that website. You get the idea.

The vast majority of cases are individual; owned by myriad businesses, charities, foundations.

The problem the OP is circling is the same as that proposed by the Social Model of disability. Most systems present obstacles to disabled users which could have been avoided if those systems' owners and designers and included disabled people in the design phase. Instead, no-one does this claiming it's too expensive, forgetting they themselves will be disabled in the future (most people become disabled in one way or another, with age). We all kick the can down the road, rather than deal with it today. Dealing with it is hard. The "national level infrastructure" aspect is a mixture of cultural praxis/expectation and, potentially, government carrot to go with the (existing) government stick (regulation; that most people try to ignore).

(I'm not saying the Social Model of Disability is 100% right. I feel it's viewpoint is hugely instructive it's not the whole story.)

> I have no idea how an adult filming young girls on a train has anything to do with social media bans.

The article is, I think, making several points at once:

- some of the people involved in creating this new legislation are already responsible for the harms the legislation alleges to mitigate. We've already heard (here on HN at least) that Meta lobbies FOR age restrictions; now with this incident we have a civic leader abusing their position of power and targeting exactly the people this raft of legislation allegedly protect (although it might be stretch to assume this person is involved in bringing in said legislation; they might be quietly avoiding talking about it because they know they're part of the problem). We should be questioning who's responsible for the legislation and inspecting their motivations publicly. We should be questioning their motivations, and challenging the efficacy of the proposed solutions given the background of motivations of those proposing them. We should be challenging the decision-making: where's the evidence the mitigations will work? (and this is all in addition to the perceived harms to all adults from the increased breadth and accuracy of the dragnet surveillance the solutions create).

- we don't need this kind of legislation to help raise reasonably-minded children. We should be targeting the perpetrators of the harm, not targeting near-adults who are (potentially) being harmed. The current legislation is victim-blaming, not prosecuting the perpetrators. The situation described is somewhat allegorical, rather than "here, social media is good"

I think it's also saying this:

- how else are people, adults, near-adults, children, going to learn of, and discuss, situations like the one described, without social media? "The Kids" have been using social media for the last ten years, and many of them are, despite the harms, growing up sane, self-controlled, able to stand up for themselves.

The article is making me reflect on our household's ban on our teen using social media. We don't want them getting wrapped up in constant one-up-ing, gossiping, body-shaming, discrimination, and other social ills that go around, but we are also denying them some ability to discuss these issues, learn about them, find support from peers and experts. (I mean, they can... they can use the wider web and can talk with their parents, friends, and teachers, in person; but those media are slower or more awkward for being "in your face")

Their product is ads slots and data, which they seem to be brilliant at. Everything else is a funnel to feed the ads, and the funnels change like wvery other marketing funnel.

AI probably should be. The bulk of its efficacy comes from the work of “everyone else” (in loose terms). AI also aims/hope/threatens to replace such a large number and range of jobs that it probabky should be a commons.

It’s a reasonable course for helping yiu identify a single line of notes across the two staves. Or maybe just the “right hand” upper/trebble clef stave (the bormal one for most instruments).

It does teach a little anout scales. It wont teach chords. It doesn’t go very far into time signatures. It only has you play a virtual keyboard so it’s useless for learning how to feel your instrument.

It’s quite fun. My kid plays it every day and it’s helped get them feeling more confident to sit at our piano and noodle around. As a noodler myself, this seems valid.

It wont get you good enough to play pieces with other musicians, or to compose with weatern harmony. You’ll need extea tutorials for those.

I agree that we had much better patterns back then. The software industry in general worked towards sharing visual paradigms, making use of system designs of their host playforms, facilitated discovery etc etc. All that was good and the recent trends moving us away from that consistency and discoverability are a detrement being steamrolled over by agents…

But I don’t agree that it “looked nice”. I hated Windows 95 and 2000’s “style”. They looked like engineers had made them. They looked stiff and unfriendly, eith too much border and outline. Real life has no outlines. I was in my late teens when 2000 came out. My friends and I jumped on it and felt it was the Os we had been waiting for.

But even then I thought it looked like shit.

The affordances were great. I agree that details like button depress and consistent scrollbars are valuable.

But I genuinely prefer things a bit rounder, a bit flatter, less grey, or late Aqua-style flat-with-shiny-affordances.

I agree that backgrounds should be flat (or very subtly textured so they recede but arn’t “boring; again, late-00s Mac OS nailed this for me).

What I’d really like to see is something new that takes the consistency of NT/2000 and Mac OSX prior to Lion, mixed with the novel affordances of BeOS/Haiku (docking windows, small title handles), and puts it through Apple’s “zing” (but not too far - transparency is highly overrated).

Context: I vibe code most of my production code, but I come from a long FED career so I'm vibe-coding small things, constantly tweaking, refining prompts, picking work to do that fits with the existing work, etc. So I'm either "doing it wrong" or "being careful". Anyway, that's the perspective I have ATM...

So, it seems to me that there's quite a lot of skill to using these "god boxes": which models, connecting to your systems, hosting the code, running the model, running the code, not breaking your production pipelines, having a production pipeline in the first place.

Sure, the god boxes help with a lot of that. But they don't help setting up the accounts, connecting your code hosting to your production servers. You can't currently just give random people in your org access to an LLM account and have them safely make production changes w/out some engineering knowledge and oversight. In NGOs, especially the small ones, they already outsource all that to 3rd parties so they don't have to worry about it. But with "just the right amount" of in-house knowledge, gear, config (maybe one office computer hooked up with Claude, or a small GHCP account, with GH + hosting configured), it's possible that anyone in the company might be able to add to the company's suite of useful small tools, or add features.

(I also think there's more to "hey claude, make feature X" than we're capturing here, but as I said at the top, I might be doing it wrong.)

Thanks for replying.

I think I missed the significance of your narrowed definition of recursion, and didn't apply it the way you intended when I read the article. I admit to my bad reading.

I went on to discuss your article with an LLM and used the experiences I've had _using_ some functional approaches in JS to help it give me a tutorial on the combinators, to try to better understand your article and the underlying principles. I "mostly get it" now, but I will have to go over it a couple more times.

You shared a thought-provoking article, even if I didn't immediately get your intended lesson out of it.

I’ll re-read it, because clearly I don’t get it. And I’d like to.

My first two attempts made it seem like it was building on a function calling itself, with itself as an argument (so that it can call itself). I’m not sure how that isn’t recursion, and I didn’t read it as throwing away those approaches. But, as I say, I’ll re-read it…

I found it extremely confusing.

It sets a challenge as a rhetorical tool, but then completely fails to honour the challenge through the bulk of the explanation.

- don’t use recursion: spends multiple paragraphs implying that a function calling itself isn’t recursion

- don’t use declaration: ignoring that defining arguments to a function is declaration

I’m not saying the article is “wrong”. But I thunk I’d have preferred a plain intro to lambda calculus.

(Writing this as someone who has struggled to learn “real” functional programming the few times I’ve tried over the past 20+ years, but who very much likes using RxJS and the functional flavour of lodash and wishes I could see deeper into that black hole.)