HN user
I don't argue against the fact that codebase complexity increases token consumption on building context. My main point was that there are other factors affecting token consumption beyond just codebase complexity. Some of them may be related to engineering culture (verbose logs, flaky tests, lack of docs, weird hacks all over the place, etc.), some of them are organizational/social.
Why do you think the cap has anything to do with the quality of their codebase? Employees could've been tokenmaxxing for various reasons: learning, experimenting, trying to impress the management, ... Naturally, this leads to AI spending skyrocketing while the business value may not be totally clear. Which leads to caps being introduced to keep the budget under control and discourage/limit tokenmaxxing.
Have you lived in one of those rent controlled “paradises”? In Europe, yes, there are sizeable populations living in subsidized housing, and often there are restrictions on rent increases, but new tenants pay way higher prices and have to compete for every available unit with dozens of other potential tenants. New tenants frantically overbidding each other, while old tenants pay pennies compared to today’s market prices, mmm, what a life.
“it can work” in some way of course. People are surprisingly adaptable to living in semi-dysfunctional environments. But it reality the only thing that truly works is building a lot of housing.
Claude's API is still running on zero-margin, if not even subsidized, AWS prices for GPUs; combined with Anthropic still lighting money on fire and presumably losing money on the API pricing.
Source? Dario claims API inference is already “fairly profitable”. They have been optimizing models and inference, while keeping prices fairly high.
dario recently told alex kantrowitz the quiet part out loud: "we make improvements all the time that make the models, like, 50% more efficient than they are before. we are just the beginning of optimizing inference... for every dollar the model makes, it costs a certain amount. that is actually already fairly profitable."
How do you jump from “not attributable to AI“ to “must be a recession”? I think it would be true for jobs that are not separable from companies economic activity, but it isn’t true for a good portion of tech jobs. A car manufacturer can’t sell the same amount of cars while reducing a half of assembly workers, but most tech giants can maintain profitable parts of their business with a fraction of their workforce (if not indefinitely then at least for some time). Some work can be eliminated altogether, some might be outsourced to other countries, some split among existing workers. I think that’s what’s happening. Why it is happening, though? Hard to say for sure, but I don’t see why it couldn’t be a combination of tighter availability of capital, shrinking addressable market (due to deglobalization & demographics) and AI competition requiring huge capex
Sure, but monitoring, reviewing and steering does not really require modern IDEs in their current form. Also, I'm sure agents can benefit from parts of IDE functionality (navigation, static analysis, integration with build tools, codebase indexing, ...), but they sure don't need the UI. And without UI those parts can become simpler, more composable and more portable (being compatible with multiple agent tools). IMO another way to think about CLI agentic coding tools as of new form of IDEs.
Fascinating to see how agents are redefining what IDEs are. This was not really the case in the chat AI era. But as autonomy increases, the traditional IDE UI becomes less important form of interaction. I think those CLI tools have pretty good chance to create a new dev tools ecosystem. Creating a full featured language plugin (let alone a full IDE) for VSCode or Intellij is not for a faint-hearted, and cross IDE portability is limited. CLI tools + MCP can be a lot simpler, more composable and more portable.
I don't understand how your comment relates to what I've been responding to.
> I know many who have it on from high that they must use AI. One place even has bonuses tied not to productivity, but how much they use AI.
How does maximizing AI use prevents developers from reading their code?
In my mind developers are responsible for the code they push, no matter whether it was copy pasted or generated by AI. The comment I responded to specifically said "bonuses tied not to productivity, but how much they use AI". I don't see that using AI for everything automatically implies having no standards or not holding responsibility for code you push.
If managers force developers to purposefully lower standards just to increase PRs per unit of time, that's another story. And in my opinion that's a problem of engeneering & organisational culture, not necessarily a problem with maximizing AI usage. If an org is OK with pushing AI slop no one understands, it will be OK with pushing handwritten slop as well.
How does maximizing AI use prevents developers from reading their code? Especially if bonuses are not tied to productivity as you say. Just treat AI as a higher level IDE/editor.
The market price is supposed to account for future growth, not just for current revenue. Predicting future is speculative by definition, but it's not completely detached from reality to bet that Nvidia has the potential to grow significantly for some time (at some point either the market cap or the multiple will correct of course).
I also see where the reasoning here contradicts the reality. If we assume Nvidia only sells $1000 gpus and moves a few millions a year, then how did it received $137B in FY2025? In reality they don't just sell GPUs, they sell systems for AI training and inference at insane margins (I've seen 90% estimates) and also some GPUs at decent margins (30-40%). These margins may be enough to stimulate competition at some point, but so far those risks have not materialized.
Yeah, I can't be sure. However, the "tech" part of the layoff most likely falls under the R&D expenses, which are relatively small compared to their overall costs. So I don't see, how cutting any number of core development workforce would make a significant difference. At least in the financial sense.
Also, I looked at the wrong year. Currently they are in Q4 2023FY, the statements for the last quarter are here https://ir.gitlab.com/news-releases/news-release-details/git...
The fun thing is that their R&D cost is dwarfed by expenses on Sales&Marketing and General&Administrative. So, if I understand their financial statements for 2022FY correctly, a 7% cut on R&D could lower their total expenses by 2% at best https://ir.gitlab.com/news-releases/news-release-details/git... Even cutting their R&D 100% would not make GitLab profitable, if other expenses are kept the same, so economics is clearly not the reason for layoffs.
Fleet does not use Compose, but it does use Skiko[1], which also provides binding for Skia[2] (the native graphics library also used by Chrome & Flutter).
The main difference between the libraries is that Skija provides Java/JVM bindings for Skia, whereas Skiko provides Kotlin bindings for Kotlin/JVM, Kotlin/JS, and Kotlin/Native targets. Of course Skiko's Kotlin/JVM bindings can be used with other JVM languages, not just with Kotlin.
The existing options for monitors, suitable for use as a TV, are extremely limited. For TVs 55" and 65" are common, for monitors there were just a few, which were dumb TVs basically. And then there are bigger sizes, different types of panels (there are no 4K QD-OLED monitors for example) that are not available for monitors. I think, if telemetry and ads are concern, buying TV without connecting it to the internet (using Apple TV or a homelab media server) is a better choice for many TV buyers.
IDE does not try to analyze Gradle scripts directly, it works with declarative model that is created by executing Gradle scripts. Gradle works in two stages: 1. Configuration: scripts execute and produce software model (DAG of tasks essentially). 2. Execution of necessary tasks in the graph.
IDE cannot get the graph by analyzing scripts, but it does not need to: instead it can ask Gradle for the model. The model itself has nothing to do with Turing completeness.
I think it's not correct to say that Turing-completeness somehow prevents extracting project structure. If a build tool can extract that information, why IDE could not do that? In fact this is how Gradle projects are imported into Intellij and Eclipse: Gradle builds project model by running Groovy or Kotlin scripts, and then IDEs are working with declarative model. The real problem is working with scripts themselves: changing them automatically (applying refactorings), providing good completion, navigation, etc. The dynamic nature of Groovy makes it much harder for IDEs to provide good tooling, but even with statically typed Kotlin it is hard because Gradle APIs are very dynamic in nature (lots of string typed APIs). That does not mean that Turing-completeness prevents good tooling completely, it just requires more efforts and has some limits depending on a build tool`s software model.
Java -> Kotlin is effectively one-way interop
Could you provide some more details? I'm a bit surprised by your statement because Kotlin team has put a lot of effort into providing mostly seamless two way interop. Kotlin project itself is ~50% Java (specifically to test interop).
Oh, it seems I've skipped "like" in "Java like VM based", sorry.
Dart is not a JVM Language. It can be compiled to the JavaScript or run in the Dart VM.
You're wrong about Gradle: it has good incremental build support. Not only it does not run a task if its inputs are not changed, it even makes it possible for a task to process inputs incrementally (e.g. so copy task can only copy/remove changed files). It does not support distributed build though.
I'm not sure if SBT supports an incremental tasks execution, but it does support incremental compilation of Scala which can be more than enough for many devs.