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.
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.
Frontier AI labs are customers just like the average Joe down the street. The only difference is who can bid more. Average Joe probably doesn't have millions or wont buy millions of chips.
There are no privileged consumers that have "dedicated" amount of production, no matter the demand.
What point are you making by saying "they're just like the average Joe" followed immediately by saying they have so much more money that they can outbid the average Joe at any price point.
If someone can dump 100x the money to get something I want, they're not "just like me".
I mean... You can buy a stick of RAM with Samsung chips on it and use it in your own machine to run a local model vs. paying for an Anthropic subscription. I assume that's what they're referring to, not owning Samsung stock.
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)
(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 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).
Wow. That is the kind of monkey business that would have me running for the exits. Yikes.
IIRC both Dijkstra and Knuth used this approach extensively, instead of "if (some_cond) break;" — partly because the latter was not yet invented, partly because of their reliance on explicitly stated and documented right in the code loop invariants.
That's fair. Let me modify my statement: If the person doing this was over 50 and had developed this habit in old languages where that was basically idiomatic, it wouldn't scandalize me - though I'd raise an eyebrow to see it in a modern language.
But if someone's 28 and doing that stuff in Python or JavaScript, they're a bit of a loon, imho.
Nah. Reduce is less performant and less readable than a regular loop. In my anecdotal experience, only people who want to appear smart and minimize the number of characters prefer reduce.
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.
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...)
I think they're kind of saying that's the problem, that intuitively having a screen inches from your face displaying things that are further away in decent detail, with things like contrast and saturation and brightness color palettes being modifiable should have some obvious possibilities for people with limited vision - but Apple wasn't interested in developing for and demonstrating these options.
I'm near-sighted, so I can see how magic glasses that let me focus on everything as if it's six inches away could be nice. That being said, normal prescription glasses work very well for my particular vision impairment, and "You only have to buy glasses once more ever, but they're $3000, weigh over a pound, and need to be recharged" isn't a great value proposition for my needs, but it doesn't take much imagination to figure that being able to toggle even just dark, high contrast, or colorblind modes irl would be nice for some people. Not worth it for me, but possibly for others.
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.
The new web page (since it's a single page website now) is also mobile friendly and intentionally not "flashy".
Another goal with the website I didn't note before is that its "quality" or "style" should generally not be consciously noticed, it shouldn't stand out for any bad reasons, people see it, get a good impression, do what they were looking to do with ease, success.
I got this philosophy from my interior designer (not to be confused with decorator) brother who told me how when he's done a good job, no one notices, but when he's done a bad job then people either almost instantly notice or simply feel uncomfortable without necessarily being able to exactly identify why, e.g. first impression of your hotel room should instantly be "feels nice" (and same with a public space in a building) and then you remain feeling comfortable throughout because the space is actually big enough for its purpose and laid out practically.
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.
reply