nice! thanks for sharing this. as always, Simon seems to be multiple steps ahead on this game.
306 karma · joined July 26, 2011
started out as a shell script but switched to a go binary (which is what is linked).
add surrounding spaces to the dash !
it's grammatically correct (but typically uncommon). visually looks more balanced to boot!
but i'm not proficient != i don't know (i.e. i have worked on javascript many moons ago, but i wouldn't consider myself an expert at it today).
i like to think i can still spot unmaintainable vs maintainable code but i understand your point that maybe the thinking is to have an expert state that opinion.
the code is [oss](https://github.com/kaushikgopal/ff-container-traffic-control) btw so would love to get other takes.
> Teams that care about quality will take the time to review and understand (and more often than not, rework) LLM-generated code before it makes it into the repo. This slows things down, to the extent that any time saved using the LLM coding assistant is often canceled out by the downstream effort.
I recently tried a mini experiment for myself to (dis)prove similar notions. I feel more convinced we'll figure out a way to use LLMs and keep maintainable repositories.
i intentionally tried to use a language I'm not as proficient in (but obv have a lot of bg in programming) to see if I could keep steering the LLM effectively
https://kau.sh/blog/container-traffic-control/
and I saved a *lot* of time.
https://kau.sh/blog/bluesky-comments-for-hugo/
I like my implementation cause it blends really well with the blog making it looks almost native.
transferring the burden of maintenance - curation to a social media platform (and a slightly more open one to boot) has been a complete win.
The key to do it without the LLM stigma is surrounding it with spaces which still doesn't violate typical writing rules.
> yet here I am more productive than ever thanks to it. i have first hand experience with most of the css frameworks. heck, even wrote a custom scss one at one point, but eventually there's a simplicity (admittedly to a fault at times) to tailwind that just makes you more productive.
> Plus people sticking to increments of 0.25rem ins this is another really good point that doesn't come through as much. Tailwind also does a fantastic job of picking the right defaults which 90% of the internet won't do.
from the OP's original piece
>> it demands the developer who installs it set up a config file that lays out all codebase-wide style constants: colors, margin sizes, fonts, border radii, etc.
... or importantly, it sets up a solid set of defaults.
fwiw, there are add-ons that allow you to do this - in one way or the other (Container Hotkeys https://addons.mozilla.org/en-US/firefox/addon/container-hot... for example).
but out of curiosity,
> I know you can set certain domains to always open in certain containers - fine for Facebook, when I occasionally have to use it - but annoying when I'm trying to do things in different (e.g.) Bluesky accounts.
on this one btw, the Containerise extension i talk about (if it wasn't clear) allows you to also map "portions" of the url in specific containers. so /u/0 in one /u/1 in another; ofc, this requires the service/website to distinguish the accounts via the url. i do this for github a lot (work repos in specific containers)
fwiw though: Zen does have other challenges at the moment with the Widevine licence. so you effectively can't use it to watch most video services today.
But point taken, from a technical accuracy perspective.
will make an edit
and fwiw, i'm also not alone in this observation. I can at least remember 2 times in the last month that, other colleagues have cited this exact same benefit.
e.g - a complicated algo that someone wrote 3 years ago, that's working well enough but has always had subtle bugs. over a 2 day workshop, we start first by writing a bunch of (meaningful) tests with an LLM. then ask the LLM about portions of the code and piecing together why a certain bit of logic existed or was written a certain way, add more tests to confirm working behavior, then start refactoring and changing the algo (also with an LLM).
much of this is similar to how we'd do it without LLMs. but no one has bothered to improve/change it cause the time investment & ROI didn't make sense (let alone the cognitive burden in gathering context from git logs or old timers who have nuggets of context that could be pieced together). with LLMs a lot of that friction can be reduced.
I think the premise is true that writing code was never the "main" bottleneck but like any power tool, when wielded by the right person, it can blow past bottlenecks.
many of these arguments,only assume the case of an inexperienced engineer blindly pumping out and merging code. I concede the problems in this case.
but put this to test with more experienced engineers. how has/does it change their workflows? the results (I've personally observed) are exponentially different.
---
> LLMs reduce the time it takes to produce code, but they haven’t changed the amount of effort required to reason about behavior, identify subtle bugs, or ensure long-term maintainability.
I have to strongly disagree here. this argument doesn't apply universally. I've actually found LLMs to make it easier to understand large swaths of code, faster. especially in larger codebases that have legacy code that no one has worked on or dared to touch. LLMs bring an element of fearlessness, which makes it easier to effect change.
My linked blog post (just a summary the above thought with aside details) points to this [youtube video](https://www.youtube.com/watch?v=JmxqOX0RN1w) doing the rounds which shows one of these AI features (magic erase) -- an example of a feature that i suspect customers will soon come to expect.
* - yes, yes Android holds a larger global market share, but the iPhone still dominates in terms of cultural influence.
Monokai was Sublime’s default but I urge folks to specifically look at the Pro version here. https://monokai.pro/
In this case, once you realize how the defaults stack, whoever came up with the one liner indeed has come up with something clever. Also the exercise in understanding the defaults cements the understanding of awk and as others have pointed out enables you to write much cleaner awk.
I enable the sidenotes based on how “wide” your current viewport is. I’ve just personally found they don’t work as well on smaller screens.
I wrote it with simple jQuery. Happy to share if anyone is interested and don’t want to have to write it from scratch.
The key to legible awk I’ve found is to not rely on the defaults that awk assumes.
(but it’s quite the mental exercise to decipher it). Feels like regex but less painful
FWIW: I did mention it in a first draft but removed it cause it seemed like fluff.
> You can do this pretty easily with Karabiner but it barely scratches the surface of Karabiner’s true power.
Karabiner is far far more powerful than just basic key mappings.
Also the linked blog post at the bottom mentions the exact point you make (viz if all you need is a caps lock to escape mapping, use the built in features on the Mac)