sasmithjr

> Once they no longer write about it, what then?

The AI will no longer be able to reproduce new a11y conventions/guidelines, but if no one is writing about it, do any new a11y conventions/guidelines even exist at that point?

I love Costco, but I get it. My wife and I always joke about how we can't leave without spending at least $100, and how that's only like 7 items sometimes.

> .NET is certainly better than Python, but I'm not very happy with the type system and the code organization versus my Rust projects.

Have you given F# a whirl?

> So there must be some other reason you didn't get revenue?

Right. I think my biggest takeaway from this article is that another engineer discovered that sales and marketing are important and difficult jobs.

For me, AI code generation for F# has been pretty good! There's one annoying thing Opus/Sonnet do (honestly don't remember what other models do): use old syntax for array indexing.

  values.[index] // Old way of indexing required a .
  values[index] // Supported for awhile now

That's the "biggest" issue I run in to, and it's not that big of a deal to me.

Yesterday, it did try to hallucinate a function that doesn't exist; compilation failed, so the agent changed the function to a fold and everything was hunkey-dorey.

I didn't look at the URL at first and was surprised when this turned in to an ad. Oh well!

> Stop selling "unlimited", when you mean "until we change our minds"

The limits don't go in to affect until August 28th, one month from yesterday. Is there an option to buy the Max plan yearly up front? I honestly don't know; I'm on the monthly plan. If there isn't a yearly purchase option, no one is buying unlimited and then getting bait-and-switched without enough time for them to cancel their sub if they don't like the new limits.

> A Different Approach: More AI for Less Money

I think it's really funny that the "different approach" is a limited time offer for credits that expire.

I don't like that the Claude Max limits are opaque, but if I really need pay-per-use, I can always switch to the API. And I'd bet I still get >$200 in API-equivalents from Claude Code once the limits are in place. If not? I'll happily switch somewhere else.

And on the "happily switch somewhere else", I find the "build user dependency" point pretty funny. Yes, I have a few hooks and subagents defined for Claude Code, but I have zero hard dependency on anything Anthropic produces. If another model/tool comes out tomorrow that's better than Claude Code for what I do, I'm jumping ship without a second thought.

> sasmithjr was apparently trying to defend babysitting A.I. by making an analogy with mentoring juniors

I regret adding that last bit to my comment because my main point (which I clearly messed up emphasizing and communicating) is that I think you’re presenting a false dichotomy in the original comment. Now that work can be done with LLMs asynchronously, it’s possible to both write your own code and guide LLMs as they need it when you have down time. And nothing about that requires stopping other functions of the job like mentoring and teaching juniors, either, so you can still build relationships on the job, too.

If having to attend to an LLM in any way makes the job worse for you, I guess we’ll have to agree to disagree. So far, LLMs feel like one of many other automations that I use frequently and haven’t really changed my satisfaction with my job.

I don't think it's an exclusive choice between the two, though. I think senior engineers will end up doing both. Looking at GitHub Copilot's agent, it can work asynchronously from the user, so a senior engineer can send it off to work on multiple issues at once while still working on tasks that aren't well suited for the agent.

And really, I think many senior engineers are already doing both in a lot of cases where they're helping guide and teach junior and early mid-level developers.

The only thing that might be tricky about FizzBuzz is if the person doesn't know about the modulo operator. I can't remember the last time I used it in production code; I use it far more thinking about FizzBuzz than I do anywhere else.

I agree people should be able to design things property, but I'm not sure this ramp is actually a good example. It might be! But no one is talking about an obvious issue for any ramp that would exist in that photo: it is merging bikes in to pedestrian traffic. So I'd think that you specifically want a ramp that forces the bike to slow down.

For another perspective, if you put 22.5lbs on each side of the bar, you wouldn't call that a "1 plate" lift even though both sides add up to 45 lbs. There are no plates involved in the lift, thus it's not a "1 plate" lift.

If you search "1 plate overhead press" or "1 plate ohp", you'll see many references to how that's a 135lb lift.

> But nothing is stopping you from running Postgres in a Docker container, and wrap it in a unit test with the technology of your choice

I agree. I'm in .NET land, I use EFCore as my ORM, and I use EFCore's migration features. My ORM models are in a separate project (same git repo) from both the web server project and test project, and any hand written SQL gets added to the migration scripts that EFCore generates.

I spin up a docker container for postgres, my test code clears any existing DB, creates a DB in the container, and then runs the EFCore migrations on the DB. I have simple tests that make sure my CTEs are working correctly and that things like expected unique indices are also setup.

This works both locally and in Github Actions.

I just wouldn't call any of this a "unit" test. I put all this squarely in my integration test suite. I figure if IO is happening as a consequential part of the test (i.e. not setup/teardown), it's an integration test. I wonder how much that distinction is tripping people up? A lot of people think of unit tests as small, independent, and quick, so by only thinking about unit testing, they automatically rule out tests that have app code call out to a DB.

Based on the sibling comment, I'm going to have to take a look at Testcontainers. I'm not sure how much it'll simplify at this point, but who knows!

> Heating up water quickly is almost never a use case.

It'd be helpful for my household for hot water for coffee and tea, and it'd also help us for heating up some extra water for grits or risotto when they need more.

Also, isn't boiling water just the measurable outcome of the test but what matters is that the pot is coming to temp sooner? Pots and pans heating up more quickly is helpful all the time.