cstrahan

https://www.eginnovations.com/blog/agentless-vs-agent-based-...

https://www.reddit.com/r/sysadmin/comments/js8h65/looking_fo...

https://www.ibm.com/docs/en/aix/7.2.0?topic=tools-performanc...

https://jolokia.org/agent/jvm.html

https://www.oracle.com/technical-resources/articles/javase/j...

Why complain about the outcome? The old game remains available, and you can play it for free. This isn’t some zero sum situation where the existence of the remastered game sets the world back in some way. I could see being more interested (or only interested) in playing the original, but I don’t see what motivates the negativity.

This is the exact example I used the other day. Same with pick-and-place, CNC for subtractive manufacturing, 3D printing for additive, plastic injection molding, etc. I wouldn't want to live in a world where the only option for products produced by such automation were instead done one-off by artisans. Sure, if you want a hand crafted laptop where everything (save for the silicon, I suppose) was hand carved, hand placed, hand soldered, etc, you should, by all means, be allowed to pay $20,000-$200,000 for that privilege, instead of ~$2,000.

It's bizarre to me that so many developers are overly attached to typing every individual character. If I could get paid for my sense of knowledge and good judgement to design software while delegating 100% of the process of creating to a team of engineers, I would. And as a staff engineer, I'm already close to that, but there are things I have to roll my sleeves up and handle myself.

It's such a stifling, self-limiting belief that it's actually saddening :(.

It's also a hypocritical belief: the machine they used to type out these thoughts were assembled in a factory, using CNC, pick-and-place, laser engraving, plastic injection molding, etc. With the exception of a few things (ex: the silicon itself) all of these things could be hand crafted - it would just make the price of computer impractical. Commoditization is a good thing, and automation is necessary for that.

I can only imagine that what is actually happening is that these people are attached to the craft of software development, and AI represents a threat to that, just as CNC milling has displaced manual machinists. But then everyone would be better off if they found an appropriate place to vent that frustration (a therapist? a friend? like-minded forum dedicated to AI complaints?), rather than projecting onto (and leveling complaints at) people using AI.

1. Were produced via plastic injection molding.

2. Were machined by CNC.

3. Have PCBs that were fabricated by machine, milled by machine, and populated via pick-and-place machine.

4. Were laser engraved, or silk screened, or printed.

5. For food/foodstuffs: were processed in an automated factory.

When you use all of these things, do you complain about using/consuming something that someone "couldn't be bothered to hand craft"?

If you don't see/anticipate the utility in a thing (like I don't have any interest in wicker baskets, hand crafted or not), why complain about that thing, instead of just moving along? I'd get it if you wanted to provide constructive feedback, but you can't do that if you're not willing to read the code.

Harboring (and expressing) negative sentiment for things that you opt to not be involved in sounds like a recipe for misery, as there's an infinite number of things to actively dislike if you go looking for them: movies/music that aren't to your tastes, mediocre restaurants, cities you wouldn't want to live in, etc.

Having an inverted index (as with FTS5) is useful in that, for a basic single-term lookup, you reduce a sequential scan, O(N), down to O(log N). For small N, the performance difference might not be meaningful. Performance gap widens with more sophisticated queries (boolean operators, ranking, etc).

Unless the loop is unrolled, yes, there is a branch to exit the loop. But then that doesn’t matter because the whole goal at the beginning was to avoid branch misprediction (which is not the same thing as avoiding branches entirely).

1) It isn’t a matter of literally “pasting into a terminal” (with the terminal emulator shoveling bytes into the TUI’s stdin), rather it’s “a TUI key-binding tells TUI app to read system clipboard”. No different than any other app.

2) This works on macOS, Linux and Windows, but not WSL. Sounds fair game to call this a bug, or at the very least a feature disparity.

Recently let Claude Code handle some commit history clean up: split a couple commits, reordered some, and identified some that could/should have been fixups, and reduced the number of commits from ~70 down to ~40. Very happy with the results and time savings.

FWIW, here’s my interactive rebase skill: https://github.com/cstrahan/claude-plugins/blob/main/skills/...

Nope. At least, not without proof. That would, IMO, be kinda crazy. We could argue semantics - maybe “stupid” would be a better word? Lacking in critical thinking skills? Whatever “it” is, it isn’t good.

Imagine old school machinists saying to a CNC machinist “Ha! See, maybe you don’t jog the axes manually, but you still have to be involved in placing the stock material, and you have to do the CAD/CAM work - so did it really machine the part for you? No!”

AI is a tool like any other. It has its limitations. It has classes of problems that it is suited to handle, and others it isn’t. If it’s true that they haven’t written (as in “typed out by hand”) a single line of code, why can’t they say that without you making that statement into more than it is?

I haven’t written a single line of code in 6 months, and that’s simply fact. It is also true that I put in a lot of other work to make that feasible, but that work isn’t in the form of writing code.

“it’s mature and the next step of engineering”

Tautologically, it’s mature enough for what it is mature enough for, and it certainly is the next step in the same way that CNC was the next step for machining — if you’re not using it as a machinist, you’re going to produce less compared to those who are.

Same thing with garden hoses. Yes, you can go fetch water from a lake and splash it on your lawn, or, you know, you could just use a sprinkler connected to your garden hose. Doesn’t replace buckets. Buckets just have a narrower scope in a world where garden hoses exist.

I’d be curious how you’d do on a hue test: https://www.xrite.com/hue-test

For me, each colored square is plainly, obviously different, and it is immediately obvious how they need to be sorted. But I also know people I’ve shown the test to who thought it was a trick - “there’s only 3 or 4 distinct colors, so how am I supposed to sort the same-colored squares?”

If one’s perception is particularly lossy, it makes sense that lower fidelity displays and audio will likely be indistinguishable from higher fidelity ones.

Nearly drove me insane, until I developed separate muscle memory between the two apps/sites.

My doc looked at me like I was crazy when I asked if it could be done without sedation, and reminded me that it would be uncomfortable, but otherwise didn't have any problem with it. I've endured 50k runs, brutal workouts, and traumatizing childhood neglect - I really can't see what the fuss is with mild discomfort that, by comparison, barely registers, and for such a short amount of time at that.

If you’re thinking of higher level libraries, involving http, html, more typical file operations, etc, what you’re saying may generally be true. But if you’re dealing with Direct Memory Access, MCU peripherals, device drivers, etc, some or all of those libraries have two options: accept unsafe in the public interface, or simply don’t exist.

(I guess there’s a third option: lie about the unsafety and mark things as safe when they fundamentally, inherently are not and cannot be safe)

See, for example:

https://rust-unofficial.github.io/too-many-lists/

https://news.ycombinator.com/item?id=22390662

> The next-gen LR parser framework for creating elegant and efficient language tools

> BABLR is a new kind of thing that does not quite fit into any category of things that has existed before it. In purpose it is made to be an instrument of code literacy -- a unified toolchain for software developers that supports a new generation of richly visual interfaces for coding. In form BABLR is a collection of scripts and virtual machines written in plain Javascript that run in almost any modern web browser. BABLR is also a community and an ecosystem, including a small but rapidly growing collection of ready-to-use parsers for popular languages.

Depends on what the aim of your labor is. Is it typing on a keyboard, memorizing (or looking up) whether that function was verb_noun() or noun_verb(), etc? Then, yeah, these tools will lower your value. If your aim is to get things done, and generate value, then no, I don't think these tools will lower your value.

This isn't all that different from CNC machining. A CNC machinist can generate a whole lot more value than someone manually jogging X/Y/Z axes on an old manual mill. If you absolutely love spinning handwheels, then it sucks to be you. CNC definitely didn't lower the value of my brother's labor -- there's no way he'd be able to manually machine enough of his product (https://www.trtvault.com/) to support himself and his family.

> Using these things will fry your brain's ability to think through hard solutions.

CNC hasn't made machinists forget about basic principles, like when to use conventional vs climb milling, speeds and feeds, or whatever. Same thing with AI. Same thing with induction cooktops. Same thing with any tool. Lazy, incompetent people will do lazy, incompetent things with whatever they are given. Yes, an idiot with a power tool is dangerous, as that tool magnifies and accelerates the messes they were already destined to make. But that doesn't make power tools intrinsically bad.

> Do you want your competency to be correlated 1:1 to the quality and quantity of tokens you can afford (or be loaned!!)?

We are already dependent on electricity. If the power goes out, we work around that as best as we can. If you can't run your power tool, but you absolutely need to make progress on whatever it is you're working on, then you pick up a hand tool. If you're using AI and it stops working for whatever reason, you simply continue without it.

I really dislike this anti-AI rhetoric. Not because I want to advocate for AI, but because it distracts from the real issue: if your work is crap, that's on you. Blaming a category of tool as inherently bad (with guaranteed bad results) suggests that there are tools that are inherently good (with guaranteed good results). No. That's absolutely incorrect. It is people who fall on the spectrum of mediocrity-to-greatness, and the tools merely help or hinder them. If someone uses AI and generates a bunch of slop, the focus should be on that person's ineptitude and/or poor judgement.

We'd all be a lot better off if we held each other to higher standards, rather than complaining about tools as a way to signal superiority.

So, what about outside of some set of categories? Well, generally, no such thing exists: new ideas are extremely rare.

Anyone who truly enjoys entering code character for character, refusing to use refactoring tools (e.g. rename symbol), and/or not using AI assistance should feel free to do so.

I, on the other hand, want to concern myself with the end product, which is a matter of knowing what to build and how to build it. There’s nothing about AI assistance that entails that one isn’t in the driver’s seat wrt algorithm design/choices, database schema design, using SIMD where possible, understanding and implementing protocols (whether HTTP or CMSIS-DAP for debugging microcontrollers over USB JTAG probe), etc, etc.

AI helps me write exactly what I would write without it, but in a fraction of the time. Of course, when the rare novel thing comes up, I either need to coach the LLM, or step in and write that part myself.

But, as a Staff Engineer, this is no different than what I already do with my human peers: I describe what needs doing and how it should be done, delegate that work to N other less senior people, provide coaching when something doesn’t meet my expectations, and I personally solve the problems that no one else has a chance of beginning to solve if they spent the next year or two solely focused on it.

Could I solve any one of those individual, delegated tasks faster if I did it myself? Absolutely. But could I achieve the same progress, in aggregate, as a legion of less experienced developers working in parallel? No.

LLM usage is like having an army of Juniors. If the result is crap, that’s on the user for their poor management and/or lack of good judgement in assessing the results, much like how it is my failing if a project I lead as a Staff Engineer is a flop.

    { [count] paragraphs backward.  exclusive motion.
    } [count] paragraphs forward.  exclusive motion.

Do you take issue with a CNC machinist stating that they made something, rather than stating that they did the CAD and CAM work but that it was the CNC machine that made the part?

Non-zero delegation doesn’t mean that the person(s) doing the delegating have put zero effort into making something, so I don’t think that delegation makes it dishonest to say that you made something. But perhaps you disagree. Or, maybe you think the use of AI means that the person using AI isn’t putting any constructive effort into what was made — but then I’d say that you’re likely way overestimating the ability of LLMs.

“A rectangle is an equal-sided rectangle (i.e. “square”) though. That’s what the R stands for.”

“No? Why would you think a rectangle is a square?”

Just as not all rectangles are squares (squares are a specific subset of rectangles), not all datagram protocols are UDP (UDP is just one particular datagram protocol).

I just explained why these issues don't apply to the LLM writing and invoking code: again, this is because code can apply successive transformations to the input without having to feed the intermediate results into the LLM's context. That code can read a file that would weigh in at 50,000 tokens, chain 100 functions together, producing a line that would be 20 tokens, and only the LLM will only see the final 20 token result. That really is only 20 tokens for the entire result -- the LLM never sees the 50,000 tokens from the file that was read via the program, nor does the LLM see the 10s of thousands of tokens worth of intermediate results between the successive transformations from each of the 100 functions.

With MCP, there's no way for the LLM to invoke one tool call that expresses "compose/pipeline these 100 tools, please, and just give me the final result" -- the LLM must make 100 individual tool calls, manually threading the results through each tool call, which represents 100 opportunities for the LLM to make a mistake.

It sounds like you are disagreeing with what I am saying, but it doesn't look you're giving any reason why you disagree, so I'm a bit confused.