I stopped using JetBrains a couple years ago. VS Code is completely free and has improved quite a lot in recent years. IMO JetBrains should focus on doing one thing right rather than having so many products.
This is hardly a novel implementation of [stream responses and chunk on sentences] + [stop on VAD and memory hole the chat log] concept. This takes <1k vibecoded lines to replicate it with an all-local setup.
I think it's important to be conscious of skill atrophy, but I don't see a problem with it if what you're offloading to AI isn't your area of focus. For instance, I don't necessarily want to always know what tricks the compiler is using to compile my program, even if they are pretty smart.
I think Mitchell Hashimoto as a pretty sane take here, where he uses LLM's to offload stuff he doesn't care about / want to think about so he can spend more time and brain power on the stuff that really matters. I tend to agree.
I doubt it's possible to draw a concrete line between in domain, and out of domain. Would you mind trying with a specific example? Because so much of engineering is understanding the interactions between systems. While I cant enumerate the exact asm codes, I do need to understand how the compiler is going to rewrite my function if I want to understand if a cast is safe, or if this function call order needs to be rewritten, or if I'm need a mutex to protect this from a torn read.
One specific example that comes to mind is developer tooling in the form of bash scripts. Sure, I can write it myself, but I do this so infrequently that there is a cost for the context switch and ramp up. This, and similar dev ex things that have been languishing in the “one day” pile because there is always the next feature to build. I can now spend 10 minutes here and there to ship incremental QoL improvements alongside my core work.
You don't have a scripting language in your toolbox that you're comfortable with?
I would probably say a shell is "the correct tool for the job" but other than the appeal to authority, or appeal to tradition. There's not a great argument for a shell script over a language you're already comfortable with.
There are hundreds of examples that are easier or faster in python than shell.
Engineers are bad at making tooling, we're even worse making ephemeral tooling we're willing to throw away. Contrasted with other makers, you have machinests who gladly make a one off tool to make a single process easier.
The more 'correct way' than a shell script, is something simple and composable. A large unwieldy shell script that you can't make simple changes in, is terrible design, and it's a mistake to allow that inertia to gain speed.
It's not exactly a complete refutation but something I've been thinking about recently.
I'm not disagreeing with your point. A good understanding of the domain and relevant systems is quite crucial. My point is that you don't always need to inspect the code at such low-level detail, provided there are tests or other ways to prove that the code behaves in the way that you describe.
> My point is that you don't always need to inspect the code at such low-level detail, provided there are tests or other ways to prove that the code behaves in the way that you describe.
This is true *only* in isolation. The pain of going through said depth of detail, is what builds the intuition for the whole system. Once and twice may not be noticeable, but a new habit, and that new habit's corresponding extreme downtime because no one understands the quirks anymore... Despite a few engineers who stake their life on the testing system, tests can't catch all issues. And it's extremely difficult to stop an oil tanker.
my starting point was Google People Management Essentials. I was thinking about team-level politics at work, and noticed some ideas seemed relevant to how teams in orgs can adopt agents. I pursued that idea more widely with other resources and it resonated.
I don't think I have any conclusions to share, just the orientation: to identify and actively accommodate the tool's cognitive style in the same way we do for one another's.
your suggestion is to treat it like a person but (surprise surprise) you don't have any specific ideas of how and why that works. your idea just sounds like marketing
> your suggestion is to treat it like a person but (surprise surprise) you don't have any specific ideas of how and why that works. your idea just sounds like marketing
oh I don't think everyone has to like these tools, and I don't think everyone has to use them. I certainly don't expect everyone to use them the same way.
We use Claude Code's ability to use skills by defining a bunch of really useful and common skills that are necessary for writing software. For e.g. brainstorming, doing test driven development, or submitting a git commit.
The specific skills you linked are interesting demos of what you can do with skills! But most of them are not useful for the day to day of building software
> Note: please help, because I'd like to preserve this website forever and there's no other way to do it besides getting Claude to recreate it from a screenshot.
Why not use wget to mirror the website? Unless you're being sarcastic.
The stuff about not being able to download it is a bit of a joke and I don't think the tone landed with everybody haha. This was just an experiment to see if Claude could recreate a simple website from a screenshot, of course to your point you could download it if you wanted.
The article sums up my current frustrations with federated platforms. Maybe it just needs some time for reliable communities to be known. But until then, I'll be happy to use centralized platforms. Alternatively, people can adapt the culture of self-hosting their own instances. Then you don't have to worry about reliability and content moderation.
reply