goyozi

An interesting version of this is when a team basically internalizes some issues in the software they work on and it turns into something they accept as a fact of life or even turn into a joke. „X failed again? Don’t bother, it’s been a shitshow for years.” What?!

A few years ago I started leading a team working on a product that had a lot of „legacy” quirks like that. It took me a good while to set a strong quality bar, both mentally and technically. I would frequently point out where the mindset was wrong, prioritize certain fixes over project work, fix a lot of issues myself, fight with other teams to fix their stuff, run silly contests such as „who solves the most support tickets this month gets a prize” and sometimes even „stop the world” for a few days until we got something in order.

Some people might be prone to think their team will never have the time to do that (and some may be right) but in my experience quality pays back. Often fixing a small bug takes about as long as discussing if it’s important, properly filing it in JIRA and then communicating to the outside world it’s not the priority. And eventually you reach a point where you have way more calm and focus than before because nothing is burning.

I’ve experimented a bit with this approach for quasi-benchmarking models. Most models nowadays will keep trying until you cut them off, they’re happy to go into millions of tokens for an easy task, digging deeper and deeper into crap design. Compared to a clean reference implementation you get easily 20x token difference at task 11+ for the same model. Somewhat ironically I never published the results because the both the harness and the task set were vibe coded and I didn’t have the energy to clean it all up.

While I wish the models were glazing less, I don't think I want them pushing back more until they get smarter. The current Opus situation where it questions good, thought-out decisions is a bit mad. It may be better if the model asked about your thought process or motivations behind certain things but I don't think I want to explain myself to an LLM all the time either.

Recent example: I asked Opus for some kind of reference data for MTBF in software. It took a few minutes to do "research", ended up providing zero data, and gave me a long essay on how DORA is superior and I should be using that instead. When I clarified that we're thinking of adding MTBF next to our existing DORA metrics, it decided I need to be thought about SLOs... if it was the first time, I may have continued clarifying but since it wasn't, I just gave up on Claude for this topic.

> clients of established products aren't really waiting for massive changes and gigantic features to be added

In some cases they do. I work in a B2B vertical SaaS company and there’s both features that competitors build or rough edges around our features that make clients go „either we get X or we sign with someone else”. I agree though with the general sentiment that you don’t need SOTA models to build those - humans or humans + mid pack strong model will do.

Fun idea, I love it!

Initially just a few sentences on what the project is about and the tech stack. Can be as little as 2 sentences + 5 bullet points.

After that it’s things I see the LLMs get wrong in practice. For almost all projects it’s when to use which build/test command + a line to use pnpm/cargo/… add instead of modifying dependency files directly + „don’t add any code comments unless specifically requested”. The rest varies a lot by project.

Holy smokes, one could call this condescending but assuming both politicians and an average reader don’t understand how exponents work feels a step above. And that’s before you get to the part where it’s all about a great idea and hard work and definitely zero exploitation while mentioning examples like Apple, Facebook or Airbnb.

No links to share but:

- a self-hosted PaaS with CI-driven deployments, managed by terraform (and possibly other IaC in the future) - think Coolify but with IaC or Komodo but easier to run full-stack apps (databases, queues and OTEL support built in)

- a benchmark for AI agents where they have to iteratively build an application - it shows how bad design decisions compound over time

wdym? Nobody's paying me or rewarding me for using these tokens. I had some spare in my subscription limit (we're not on token pricing), so I decided to try an ambitious task that may reduce our CI times and improve our DX significantly. That's hardly "the entire token-maxxing AI hype train in a nutshell".

Well, I used an extreme example. OTOH, I’ve done quite a few of those „fix CI” or „migrate X” prompts recently and while there is a fixed component like running CI / builds, I’d say the LLM time is still around or above 50%, especially at the beginning of the project. Then there’s also regular tasks that now take minutes per message which completely get me out of the zone. I imagine iterating on those in near real time would be a big change.

I replied in more detail under another comment. TLDR: fixing flaky CI across multiple branches

I’m rewriting our integration test suite to run tests in parallel. I have the changes split across 7 branches, and each needs to be fixed to have no flaky tests. I told it I want 3 consecutive CI runs with no flakes and no artificial fixes / assert removals etc. We’ll see what comes out; it’s almost a side project so there’s not much to lose other than some of my weekly limit that resets soon.

Fast AI seems genuinely exciting and somewhat unsettling to me. Right now Claude is faster than me on some tasks but we’re at least close. I have a prompt to clean up a PR that’s been running for 1h now and I expect it to take another few. It’s hard to imagine how the workflow would look like if it was near-instant. On the one hand, it might be easier to focus. Some prompts take so long that I start to multitask and regret it later. On the other, AI that takes a few seconds to max few minutes to solve what used to take hours or days? That’s a game changer and I don’t even know where we fit in.

The answer is quite simple, even if not satisfying: - recommendations take time to re-calculate - downvotes are not a global exclusion filter

There are a lot of approaches to recommendations, and I imagine the biggest players having a mix of them, so that _something_ sticks. Some of them might rely on data / features / models which are recalculated "once every X", so they don't react immediately to your input.

There's also patterns which are normal to some people but seem insane to others: "oh, I've liked this show so much I watched it 3 times!".

I don’t follow the debate and situation in the US that closely but isn’t (part of) the point of wealth tax to offset the fact that rich people are routinely avoiding paying income tax and taxes in general? Thus even if we assume the simplistic conversion here, it’s not that they’re moved from 40->60 bracket but more like <10 -> <30 ?