ryanbrunner

Try flipping it, that's what I do. I usually prompt AI for research, absorb thta, write my own thing, and then ask AI to proofread it and I'll let it fix small grammatical errors and typos, while larger structural suggestions I'll still implement myself. It doesn't take much more time in my experience and I'm infinitely more satisfied with my output.

I would say the vast majority of people outside a tech bubble will not be offended by "we didn't use AI to write any of this" (the converse might be true though!)

As other people have said, if I wanted AI slop I'd just ask Claude.

Maybe better phrased as "another human". If you're prompting AI for your own purposes that's totally fine, just absorb the information and summarize it for people instead of just dumping AI output directly on them.

It's expected to call out people (usually in DMs) when they post AI generated stuff. Occasionally people will link to a claude doc as like an "additional details here" type note, but that's the extent of it.

It's entirely possible that people have just finely tuned AI to perfectly mimic them, but if it passes the Turing test, I guess I have nothing to complain about. Our rules are less about some fundamental opposition to AI and more that it's just annoying to read unedited AI slop.

Our workplace are heavy users of AI for nearly everything, but we still hold to the rule that if the audience of text is a human, it should be written by a human.

AI generated text is still exhausting to read.

I created this to make working with agents on the review cycle of tasks easier, but I've found it really useful to start something new too - spin up a session on a part of an app you'd like to make design improvements to, and you can interactively work with AI on improving it.

The obvious difference between your experiences and the person you're replying to is that he's residing there and you're visiting. You're right that your rights are far more limited when you're a visitor to a country crossing a border, but he and this thread are talking about what rights residents to a country have regarding the border.

They have to demonstrate value absolutely, but you're forgetting about the denominator of cost, and to a large degree so is the industry right now.

To take this argument to an absurd level, if Fable generating a feature cost $100,000 and Sonnet generating the same feature cost $1, it wouldn't be enough that Fable is marginally, significantly, or even dramatically better, because the cost difference is so outsized. For a variety of reasons, the true cost of tokens for frontier models is downplayed at multiple points (whether it's through AI companies running off funding, companies prioritizing AI adoption over AI costs, etc.)

If cost is not an issue at all, the best thing is always preferable regardless of cost. But in most cases, and AI is no exception, eventually cost will be an issue.

An easy counterargument is that the frontier models are swallowing all of the attention and money because they currently don't have a constraint of demonstrating that their value exceeds their cost. Take that away and it might turn out that cheaper models that are "good enough" and can be profitable are the more attractive route.

The value of those models doesn't necessarily though. To extend the personal computer analogy, a server rack has always been more powerful than the average desktop computer but a personal computer got "good enough" at enough tasks that people just used those instead.

Do you store your CSS in separate common files independent of markup? Out of curiosity, do you run into issues with excessive token usage when you want to work with CSS?

That would be my gut instinct - you ask your agent to change a CSS rule, and your agent would feel the need to find all usage of that rule to avoid introducing unexpected changes. Does that happen? (I'm operating purely on assumptions here because I regularly use tailwind where changes are kinda definitionally local).

Articles like this remind me of that Innovation Tokens article.

Your time and attention is precious as a developer. I'm absolutely sure it's possible to implement uniqueness constraints, transactions, indices, and history yourself, but is that really the most valuable use of your time? There's probably not a need for you to have a unique solution, so you're quite literally just re-inventing something someone already had for not a lot of benefit.

Wouldn't your time be better spent actually solving the problems that whatever you're building is supposed to solve?

It's common to want things that look like buttons that functionally link to a page.

This isn't really straightforward with the HTML `button` tag so `a` tags that appear like buttons are common. I'm not really proposing something out of the ordinary here, nearly every high level component library that has a built in "button" will support applying them to `a` tags and most likely have that as their primary example of a button.

In my experience, if you're going to aggressively componentize whatever you're building (i.e. a button isn't a css class on a simple `a` tag but a distinct component that exists in it's own file somewhere) there's huge advantages to having your styling be associated directly with your components, and Tailwind is a great option (among many) for that.

If you're building something where your unit of organization looks more like a "page" than super fine grained elements, Tailwind will just make things messy and a higher-level library or writing your own CSS would be a better approach.

I don't think this changes much with AI - right now most models are not terrific at maintaining a huge degree of context in larger projects, so I could absolutely see an agent implementing CSS that works well in isolation but breaks due to the cascade. Maybe that changes in the future, but right now if anything I think Tailwind is well suited to AI because it enforces a certain locality to the changes you're making (i.e. you can reasonably assume that a `text-red-500` class on an element isn't going to break things elsewhere and wll do what it says on the box).

What AI replaces isn't Tailwind (AI will reach for Tailwind pretty readily), but the paid ecosystem that was Tailwind's business model. The value of having a pre-built component goes down when building that component is a 10 minute job of an agent.

I think there's plenty of developers that are perfectly competent with CSS who still reach for Tailwind.

You're right that Tailwind throws away the cascade, or at least enables developers not to have to think about it (under the hood, Tailwind 4 uses pretty modern cascading features like layers), but people aren't reaching it because of a lack of understanding, they're reaching for it because as front-ends get increasingly componentized, the cascade becomes less and less of a benefit and more of an obstacle to be worked around, and something that gets that obstacle out of the way becomes more attractive.

I think if you said "couldn't be a venture backed startup", I'd 100% agree with you. Can't support employees or a marketing budget is a much lower bar, and I think that's perfectly achievable by something like Tailwind (or I guess was prior to AI)

The problem with this approach (that their first example already demonstrates), is that you'll almost immediately start with a "this type of file is OK" solution, and whether something should go in git doesn't really have a super strong correlation with file type.

It hobbles `git status` and essentially forces you to keep track of what you've changed yourself (since ignored files won't show up there), and it can instill a false sense of security that `git add .` is safe when it might not be.

I find the other direction works ok as well - Sonnet 5 with Opus as an advisor - all the "Opusisms" get hidden from you since the convo is between Sonnet and Opus but you still get pretty decent results.

I don't think there's any functional difference between "chat about this" and just directly entering what you'd like to do / ask about in the "Tell Claude what to do" option, I think that's pretty much exactly what you're looking for.

In this hypothetical, at that point, those people are going to be literal no exaggeration oligarchs (arguably they are now) - just saying they should give up what would amount to a large percentage of their wealth isn't going to go over well.

1. There's far less product managers 2. What makes you so sure that product managers won't be automated away? The breathless pronouncements from the people running these companies aren't that there won't be software developers, it's that there won't be knowledge workers.

I think what I intended to get across isn't too incompatible with what you're saying. I think it's fine to say "this function is too long", and long functions generally speaking should be something that's worthy of a code review comment.

I think the issue that originally launched this thread of the discussion is people who take the specific rules to a dogmatic level and apply rules blindly, and transform "functions should not be long" to "functions should be less than 20 lines no matter what". 20 lines (or whatever standard you land on) should be a guideline and not an inviolable law of the universe, and if reducing a method below 20 lines harms comprehensibility and readability, you're letting the guideline get in the way of the actual goal.

Sorry, you're right - 20 lines or less is the recommendation in the actual text of Clean Code. I have seen people try to push that down to 5 in Ruby on Rails development (IIRC, the most popular linter at one time tried to enforce 5 lines)

In any case, the point stands - there are 19 line functions that are too sense, and 21 line functions that are sensible.

I think the rule that "functions should be small enough that they should be easily reasoned about" is a reasonable rule, and it makes sense to follow it 95% of the time.

"Functions should be 5 lines or less" is a measure that approximates that rule, but isn't exactly the same thing - I hope you agree we could both come up with 4 line functions that are impossibly complex or 6 line functions that are easily reasoned about.

I think with Clean Code (and a lot of these kinds of things - Design Patterns is a great old example of this), people can get too dogmatic about applying these sort of approximated rules, when it would make a lot more sense for someone else (i.e. not the code writer) to use their best judgement and just directly answer the question "is this function easy to reason about?" rather than using the approximate measure.

Fortunately we are humans, and professionally trained humans at that, and we can judge readability and comprehensibility of methods through better measures than whether it crosses a boundary of number of lines.

There is absolutely a place for PR reviews, and I don't think the person you were replying to was against that, just that PR reviews would be better by actually judging things like readability directly rather than relying on measures that estimate those qualities.

I can think of many times arbitrary rules like linting or Clean Code-esque standards resulted in a "solution" of making my code less readable.

The difference between "if you have nothing to hide" and the argument you're replying to is that "if you have nothing to hide" is used as a justification for why it's not a problem for authorities to be able to randomly search you, while the parent comment isn't attempting to justify, just acknowledge the reality of the situation.

A blank phone is suspicious in and of itself and probably invites more questioning and suspicion.

And from personal experience, once a border guard is suspicious of you and you're a non-citizen, you're fighting a losing battle to get into that country, regardless of whether you're doing anything shady / illegal.

The most straightforward answer I think is to use common apps for more commonplace social media activities and separate apps that can be removed from your phone when you're crossing a border for things you want to keep private. It's not perfect privacy, but I think a border is one thing that for better or worse you'll need to accept some compromises on.

Outlook.com also seems to routinely ignore DMARC (it will bounce emails with a DMARC that's report only)