vemv

My (tragically) favorite part is, from wikipedia:

> A commission attributed the primary cause to generally poor software design and development practices, rather than singling out specific coding errors.

Which to me reads as "this entire codebase was so awful that it was bound to fail in some or other way".

It will increasingly become common knowledge that the best practice for AI coding is small edits quite carefully planned by a human. Else the LLM will keep going down rabbit holes and failing to produce useful results without supervision.

Huge rules systems, all-encompassing automations, etc all assume that more context is better, which is simply not the case given that "context rot" is a thing.

A sizeable chunk of well-recognised founders are simply scammers - they take VC money, sell dreams to customers, and exploit engineers as a necessary step to keep the ball rolling.

Think of the operation of a pump and dump with extra steps. The mission is never about creating value, it's about pumping expectations and pulling the rug at the right time.

Maybe a few of them live in the delusion of improving society with their products, but even then, the fact that they don't give a damn about the quality delivered to customers (or are qualified to make any technical judgement) makes them de facto scammers.

What I often do, and completely works, is telling Claude Code to git-clone the library in question. Then I /add-dir it, so I can tell it to understand the code factually and as of the exact version I'm using.

You often don't even need cloning, for instance in the Ruby ecosystem, for the Pundit gem `bundle show pundit` tells you `/Users/vemv/.rbenv/versions/3.4.5/lib/ruby/gems/3.4.0/gems/pundit-2.3.2` which is a vanilla dir (non-zipped), ready to be added to the Claude context.

I came here to say this!

> I think it is mostly AI founders hyping up their AI products. "Now you too can become a billionaire overnight, if you just completely integrate these AI tools into your workflow!"

Yep, and it gives me Ponzi vibes.

I stay in the loop by reviewing each edit and telling it to do something differently asap if something was wrong.

The opposite approach is also possible: just hit the option (or .json setting) to accept all edits. Then you'd review the persisted changes using your favorite Git tool.

Overly short limits butcher semantics, killing a sense of rhythm and continuity. I'm not reading a raw stream of characters, but a sentence-like message intended for humans to understand.

Overly long lines have a similar flaw - they compress too much information, so there's quite literally, no rhyme or reason.

So my approach is to have some sort of honor system: write something that you believe that will be readable to a variety of humans, where similar things are grouped together, and different things are laid out apart.

I do have a limit like 240, but that's more like a guardrail, not an invitation for every line to be that long.

When it comes to diffs (edits), Cursor is batch-oriented, while CC suggests one edit at a time and can be steered in real time.

That's a critical feature for keeping a human in the loop, preventing big detours and token waste.

It gets routinely ignored. Been there done that.

In my experience as an early adopter of both Cursor and CC, nothing. I don't have a CLAUDE.md.

My expectations have shifted from "magic black box" to "fancy autocomplete". i.e. CC is for me an autocomplete for specific intents, in small steps, prompted in specific terms. I do the thinking.

I do put effort in crafting good context though.

Yes, I've had such a system in the back of my mind for a few months, mixing and matching cheaper/local and more expensive LLMs.

Sometimes I've wanted to implement it but I sense that someone else will sooner or later, putting in more resources than I could currently.

In the meantime I'm happy with vanilla CC usage.

> Said person does not give a shit about whether things are correct or could even work, as long as they look "somewhat plausible".

Spot on, I think this every time I see AI art on my Linkedin feed.

I'm not gonna lie, that ~/.claude/CLAUDE.md is not going to work.

There are a lot of subjective, ambigous instructions that really won't affect what Claude writes. Remember it's not a human, it's not performing careful reasoning over each individual LOC.

Context rot is a thing (https://news.ycombinator.com/item?id=44564248 ).

As of today, you cannot squeeze a true rule system out of a single file given as context. Many of us have done this mistake at some point – believing that you can specify arbitrarily many rules and that they'll be honored.

If you really care about every such rule, you'd have to create sub-agents, one per rule, and make the agents a required part of a deterministic (non-AI orchestrated) pipeline. Then costs would explode of course.

I'm happily using https://github.com/stevemolitor/claude-code.el which is a mere terminal wrapper (including a nifty Transient menu). But just by virtue of running inside Emacs you get a lot of power - it didn't take me a lot of effort to create an efficient, customized workflow that felt much more streamlined than my older iTerm usage.

I'll keep an eye on this new offering though.

There's also https://github.com/editor-code-assistant/eca-emacs which comes from the author of clojure-lsp, a very popular package within the Clojure community. I'd also been wanting to try it.

For both of the more advanced offerings, I tend to be a little cautious when adopting tools I'm trusting my productivity to. Most ambitious projects need to iron out misc stuff during their 'big bang' phase.

Thanks! Applied (V. Valenzuela).

I have a specific track record in building developer tooling (I've been awarded 3 different well-known grants) and have been an early adopter of AI tooling, so this would sound like an exciting opportunity to me.

Not sure if I see the Software Engineer (full-stack or backend focus, Senior) role

Applied through LI, I included a cover letter over there.

https://github.com/vemv https://www.linkedin.com/in/vemvdotnet/

There are infinitely many runtime properties that are simply impossible to determine statically.

Static typing is just a tool, aiming to help with a subset of all possible problems you may find. If you think it's an absolute oracle of every possible problem you may find, sorry, that's just not true, and trivially demonstrable.

Your example already is a runtime check that makes no particular use of the type system. It's a simple "set contains" check (value-oriented, not type-oriented) which also is far more expensive than simply verifying the string prefix of a Slack-style object identifier.

Ultimately I'm not even saying that types are bad, or that static typing is bad. If you truly care about correctness, you'd use all layers at your disposition - static and dynamic.

Most static type systems that I know of disappear at runtime. You literally cannot "use" them once deployed to production.

(Typescript's Zed and Clojure's Malli are counterexamples. Although not official offerings)

Following OP's example, what prevents you from getting a AccountID parsed as a UserID at runtime, in production? In production it's all UUIDs, undistinguishable from one another.

A truly safe approach would use distinct value prefixes – one per object type. Slack does this I believe.

We gotta know if the humorous prompt engineering you laid out in June's post gave interesting results.

Best of luck with the search!

Cursor in particular but also others are extremely flaky when it comes to applying rules.

So the next generation of "rules" for Cursor, Claude Code, etc should have some predictability baked in, i.e. not be entirely driven by AI.

Having rules driven by a vanilla, non-AI program ensures that they're actually, consistently applied, with some logs showing if/how they were applied.

Of course, one can augment vanilla rules with some AI capabilities, but the main orchestration should resemble determinism.

I suspect that the main reason why this isn't a reality yet is because costs could easily skyrocket. Personally I'd be willing to pay the extra buck if that means that my comprehensive rule system is actually doing something.

The internet would be such a great way to connect all the peaceful people around the world and boicott the elites that are wreaking havoc.

I don't think a significant amount of Americans, Europeans, Russians, Chinese, etc genuinely wish the decline of any of the other countries. It's just their leaders that create these situations and force us to pick a side.

What's the best next choice if I don't want to move away from a Chrome-like experience?

(Old habits die hard)

There's https://github.com/ungoogled-software/ungoogled-chromium - is it a sound choice nowadays?

It's not entirely clear if you are seeking a+b+c, or 3 individual contributors.

This doesn't work because competition and/or free usage become trivial.

As a long-time professional RoR developer, I disagree with the article's premise.

AI seems like the last nail in the coffin for an easy, slow-evolving, highly standardized ecosystem like Rails'.

In short, using Rails was already pretty easy pre-AI, now it's just too easy. That might be nice for misc purposes like prototyping something, or teaching people how to make webapps, but for all other purposes it makes us disposable peons.

Even in better times than 2022-24, I expect Rails salaries not to grow particularly. I don't expect it to die either - probably it will be not unlike PHP: easy, pretty nice, but ultimately a voluntary choice to have a lower salary.

I thank Ruby/Rails for various aspects that have made my career better, but it's wiser to move on to something more niche and that doesn't pretend we're still living in 2008.

> In the early 1980s, Dallas Fort-Worth Airport covered as much land as the city of Dallas did, and Denver International Airport is as large as the city of San Francisco.

This... doesn't fit into my head.

> The idea that prospective employers will look at open source contributions to evaluate job applicants is now, thankfully, understood as pernicious.

Says who?

This is very much an unsubstantiated claim - no reasoning behind it and the naive assumption that everyone agrees with him.

I second the sentiment, however I'm not sure that the market is 'saturated' with talent. The need for productive devs remains there, companies just lack the investment money (and/or cannot spend it due to the US tax situation). Products, teams are struggling as a consequence.

The moment investment comes back, so will be jobs. In the end it's that easy.

I've vouched (voted to remove from flagged) this comment.

With that said, what was the typical salary for one of those positions?