> 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.
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.
- 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’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 ?
All of the growing pains listed in the article can be observed in pretty much any framework in any language. Certain patterns and designs might be more present in some environments than others but I’m yet to see a framework that still guides you at tens or hundreds of kLOC. I don’t see how Rails is an issue here. If anything, I’ve always liked how the Ruby/Rails community discusses how to get the best of their framework and object-orientation. Are there monstrous, hard to evolve Rails app? Yes but the same can be said about Spring, .NET, Django and many others.
I feel like I had the best and worst ~month experience on 4.6. Initially when it came out, it seemed to ask good questions and genuinely do well on complex tasks. From about mid-March it was absolutely abysmal, it seemed to assume the stupidest answer/angle for everything and make weird mistakes. 4.7 seems decent so far but usage hurts - at some point my company switched me to standard seat and I used up 80% of my session usage in 1 prompt. I got my premium seat back since but I think pro/standard plan + opus 4.7 is unusable for daily driving.
These are very good numbers. I still don’t get why they don’t compare against latest competitor versions in these posts, it’s not like we’re all not going to notice.
Not saying it’s good but I think it’s quite common for devs to have read only access to everything. I suspect that with all the recent news, including this, the needle might start to shift a bit.
I think it’s actually non-trivial to determine how many repos you should have read-only access to. I frequently hop through multiple repos that I don’t contribute to, just to understand how the system is architected and what it does at different stages. We even have an internal Claude skill for finding relevant repo for a given problem which relies on personal gh access (via CLI). It _can_ be done more securely but those defaults built over many years will take time to change.
I kind of want to try it, to see if and how far they can take an open model and improve it but I really don’t miss the Cursor user experience. Constant UI changes, half-baked features, smaller and smaller limits, useless AI change attribution; I think I’ll wait for others to report if it’s any good.
As for why we are not worried enough, my guess would be that we’re too preoccupied with the impact on coding process itself, there isn’t enough attention put on other parts.
In terms of general working practices, there’s 2 things that I think are important right now:
- proper AI attribution - both on commits and AI-generated PR comments. A bit of extra transparency can help spot these kinds of issues
- clear separation of human and automated PR review
As an example, on that second point, we already use CodeRabbit for AI-based PR reviews. If I see „John” approving a PR, my expectation is that John himself read it and is vouching for it. I’d expect that AI is not involved or, at most, it does non-opinionated explaining and/or ordering of changes. If I see any kind of mention that „Claude did code review for someone”, I’m going to start screaming.
Really neat, I’ll have to try it when I’m at home. Lean, fast tools really make a difference in the coding experience.
I’m curious how the prompts idea performs in practice compared to typical skills and subagents. I frequently combine the two to get otherwise tricky workflows done. Say I have a failing build. I invoke my /fix-ci skill (sometimes in the same context I made the code change in), it launches a subagent to extract an error message / stack traces / relevant logs, and works through the problem. Say an integration test ran into a db query issue. Sometimes the agent itself, sometimes with a slight nudge from me, will load the readonly db access skill and start investigating. If I expect long, deep shenanigans, I’ll often say something like „use a sonnet subagent and instruct it to use the db query skill to debug the behavior we’re seeing”. And it can keep going like that: skills give extra capabilities on the fly, subagents isolate context to prevent bloat. Intuitively, it seems that by the agent running itself via bash with different prompts _might_ come close but a bit less streamlined? I’d have to check and see.
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.