Sounds like they're still giving the model the keys to the kingdom, which is my point, stop giving the model the avenue to do catastrophic mistakes, it makes no sense.
If you’re message is in response to me, which I think it is, I deliberately don’t give access to credentials and env variables. I’ve worked to create restrictions and seen AI models use very interesting methods to bypass them.
Even now my prompt says the AI must verify the path of the files it intends to edit, and get permission before editing one file at a time and only after permission. I stop it from ignoring those rules once a day at least.
I built www.propelcode.app with separate Linux containers, unless you disconnect the container and your computer from the internet the models can escape the sandbox and get information off of your machine.
I am open to being corrected and learning from you if you have a better method of sandboxing
I am using tmux but not disposable vm. I have thought about something like that but honestly some of the debugging work makes ephemeral environments hard to work with. How are you doing that in your workflow?
We kinda need to architect things with the assumption that all token-output from an LLM can be unpredictably sneaky and malicious.
Alas, humans suck at constant vigilance, we're built to avoid it whenever possible, so a "reverse centaur" future of "do what the AI says but only if you see it's good" is going to suck.
I built my own IDE to replace vscode / cursor so I could design the harness and ensure that the model tool access was secure and limited. But the rest of the industry is YOLO
Exactly one year on from Oniguruma's archival on GitHub and fancy-regex is in a pretty good position to act as a compatible, memory-safe alternative.
Since the previous release, fancy-regex now has support for subroutine calls - although relative recursion level backreferences are still currently unsupported.
There also a PR with an experimental optimization, which may get released soon.
Didn't know that! I tried it and it doesn't work for me, sadly. Test case: `seq 1 100 | bat --pager=builtin` Result: immediate exit, no output printed at all.
This resonates with me for a couple of reasons. One is that despite a good AGENTS.md file and a detailed, specific prompt, I've seen LLM agents generate all sorts of questionable code. From making a mistake, running tests and fixing the mistake meanwhile adding a comment which only makes sense when you read it from the perspective of having seen it make that mistake... As soon as anyone else would read it, there is no context and it can be confusing or misleading...
Or naming tests only considering the specific task at hand, which is meaningless when compared to the grand scheme of things.
Yesterday I had GitHub ask me to complete a survey on it's Copilot coding agent, and it made me realize that some obvious things were missing from my AGENTS.md. Notes that are unnecessary to be written "normally" because it aligns naturally with how human programmers work. When writing a new unit test in a file full of unit tests, I typically copy an existing test which has roughly what I need, paste it and adapt it. Or at least look at existing tests when building a new one. I've seen LLM agents ignore private helper methods and do full integration style tests for new test cases because they don't work like that unless specifically instructed...
So yes, I definitely feel that AI can increase tech debt big time unless managed carefully - paved roads are the way to go for human developers and AI agents. It does get tricky when you need to branch out and do something new or never considered before though...
I personally really enjoyed this article - thanks for sharing.
I have worked for companies which use OKRs to help decide what they want to achieve, but it was never clear to me how they decide what features to implement to reach those goals.
Seeing the "impact, confidence, and ease scores (ICE)" concept and how it should be done is quite an eye opener for me. Maybe that has been done where I work, just never shared with me - a lowly senior developer, who knows...
You can still connect AirPods to an android device using Bluetooth, you just don’t get the seamless connection or support for Spatial Audio that use the extended protocols
> Why use Bluetooth at all if they don't actually use it properly?
Because they needed a way to get audio to the AirPods wirelessly and to work with their devices? That’s a pretty good reason to use Bluetooth.
I doubt they got together and tried to scheme a way to break Bluetooth in this one tiny little way for vendor lock in. You can use the basic AirPod features with other Bluetooth devices. It’s just these extended features that were never developed for other platforms.
HN comments lean heavily conspiratorial but I think the obvious explanation is that the devs built and tested it against iPhone and Mac targets and optimized for that. This minor discrepancy wasn’t worked around because it isn’t triggered on Apple platforms and it’s not a target for them.
It reminds me of the USB keyboard extender that came with old Macs. There’s a little notch in the socket so you can only use it with Apple keyboards. At the time I thought it was a petty way of preventing you from using it with any other device, but apparently the reason they didn’t want you to use it with other devices is because the cable didn’t comply with the USB spec.
Yes, USB extenders are not spec-legal (because the device isn't built expecting to be extended).
But you can have an extension cord which accepts USB on one end but doesn't accept USB on the other.
So the keyboard has a superset connector so that it can go in regular USB and notched USB, because it is verified to work right when using the extension cord.
This design also means you can't plug one extension cord into another to get an even longer distance (which the keyboard wouldn't expect). Pretty clever solution.
I tried using Mergiraf a year or so ago, and ended up with so many weird problems that I eventually tracked down to being caused by it, that I disabled and uninstalled it and never looked back - it was more hassle than it was worth
Having to pipe to a pager - to follow the unix philosophy - means:
- extra typing each time
- the pager receives static output. There is no interactivity... Sure, most pagers can search. But there is no way to have a table with adjustable columns, or toggle word wrap or line numbers etc.
I feel that for a tool like bat, it is better to have it built-in and not follow the composable philosophy because it is just so much more convenient.
Of course the minus integration in bat is fairly basic at the moment, I guess supporting different code paths for static pagers vs interactive would increase maintenance burden quite a lot...
The `less` command can toggle line numbers (`-N`, either as a command line argument, or while running it interactively) and toggle line wrapping (`-S`, again either way). It can also receive streamed output with `+F`, making it a viable alternative to `tail -f`. (I'm not sure if what you meant by static output is that it all has to be available before the command can read it.)
It can't adjust the columns in a table, but then I don't believe that `bat` can either, and I'm not aware of any similar program that can. (If there is one, please let me know.)
In the case of `bat` (or `man` or other programs that use a pager) it often requires no extra typing either, since `bat` will pipe it's output to `less` by default (or whatever you specify with the `PAGER` environment variable).
The `less` command can be quite a bit more powerful than it initially looks. I'd recommend looking over the man page sometime -- you might be surprised. In fact, looking over the `minus` page, other than being able to be compiled into another program so it doesn't have to be shipped separately on Windows, I'm not sure what it can do that `less` cannot. (If I'm missing some killer feature, please let me know. I'm not trying to bash `minus`, I just don't know what more it offers.)
Isn't that what branch policies are for? It can get annoying when making a release (from a local machine as opposed to automatically in CI/CD pipelines), but in other circumstances it serves the purpose very well in my experience
git itself has no concept of branch policies, it is purely a server side thing. But surely it doesn't really matter what branch you commit to locally, if you can't push it, you haven't done any damage and can just create a new branch and push that instead?
Yes, but I'd like to avoid the "create a new branch, switch back to main, reset main back to origin, come back to the new branch" dance. And a git hook does that, but it's not trivial to set up (particularly when there are lots of repos).
The solution could be a pre-push hook. I am also not a fan of pre-commit hooks because I just want to commit my wip changes. Not stash. Commit.
It's fine if the auto formatting tool hasn't been run. If the pre-commit hook changes my files silently, that is a big no-no for me.
I have had tools break things before and it makes it very hard to work out what happened.
Having it fail to push means I get to choose how to fix up my commits - whether I want a new one for formatting changes etc or to go back and edit a commit for a cleaner public history.
I used to think pre-push was better than pre-commit but at some point I realized I was actually just kicking the can down the road and leaving bigger problems for myself. It's not downsides-free, but it's the better compromise for me.
