I actually am spending some of my money in an attempt to contribute to decrease some of these things, and investing bit parts of my retirement plans in others.
I understand that some developers produce very poor code. Maybe in some companies it's the norm. Luckily for me, I've seldom worked alongside such developers.
In my company, the code Opus 4.8 is able to generate appears competent, but if you dig a bit, it contains way more timebombs than anything I've seen the team members develop.
My conclusion from the project I'm working on is that, as of this day, there is no way to have both this so-called 20x performance improvement _and_ any kind of quality. Or security if whoever is running the agent has any token in an .env anywhere on the same file system.
We'll see in which direction the CTO takes this. My bet is not on quality.
Eh, Firefox/Thunderbird had multi-threaded JS in SpiderMonkey in the late 90s.
Then it was removed it because it made garbage-collection a real mess (the JavaScript gc needs to walk through lots of C++ data, some of it may have specific requirements for destruction/finalization).
> Engineers over-engineer simple problems because their performance reviews reward technical complexity, not business impact.
Having tech led teams at both high-profile and low-profile tech companies, that is _not_ my experience.
Most engineers worth their salt value quality. Product Management generally doesn't see quality as a feature, therefore doesn't take it into account. For short-lived code, quality is indeed over-rated. For long-lived code, quality is the thing that determines whether you can keep improving or tuning other features or whether you'll miss deadlines. Sadly, retrofitting quality in an existing codebase is awfully expensive.
There's also one important, but often undervalued, aspect. Overwhelmingly, today's tech world has been built by neurodivergent engineers. In my experience, neurodivergent engineers tend to value getting to the end of things, rather than letting them drop mid-way. This can absolutely be seen as over-engineering, but it's often a cognitive scaffolding that will ensure that the work can be resumed (by them or anyone else) even after context-switching to something entirely different.
Whether it actually _is_ over-engineering often depends on how well the engineer is aware of the actual needs, rather than being spoon-fed instructions without visibility. Or on the maturity and skill of the engineer, depending on the case.
Directly at DeepSeek? It was my understanding (but I didn't check) that some other AI operators were providing (some of?) DeepSeek's model for cheaper prices.
Still, that's interesting. What do you get for that price? Only coding, or also e.g. image generation?
I'm assuming that you need to feed the human being (i.e. you) regardless of whether you use that human being for writing code or not. So, by this metric, there is simply no breaking even point. The cost of human + AI is always going to be higher than the cost of human.
Anecdotally, a few weeks into a Rust agent-first project, we're still trying to get the agent to maintain a minimum of coding discipline (e.g. don't use sync Mutex in tokio code). So far, the agent seems more interested in deactivating the linters than in complying.
Security? At this stage, I'm a bit afraid that it's a joke more than anything else.
> Why on earth would AI labs be bragging about how little the product they sell actually costs them to make? You don't want to do anything that reduces it's perceived value to the user, that might make them less willing to pay for it.
Wouldn't they be bragging about it to investors? It feels like something that would matter a lot to them, and at least OpenAI kinda feels desperate to find them.
There's also the small question about whether a drop in inference cost would actually change anything about profitability, when training seems to get exponentially more expensive.
It seems that this era is a marketing experiment for Mythos.
We're running forward without any idea of how we can get agents to write code that is even remotely safe or secure. It _will_ blow up with increasingly large blast radiuses.
Go is pretty good at performance, but pretty bad at expressing domain-specific logics. Python is the opposite, but once you have isolated the parts that need to be optimized, it's quite easy to rewrite them in a native language (in particular, the Rust-Python bindings are really good, although in this project, it's C++).
When I was a manager in a start-up, ages ago, I argued the CEO against handing a (small) one-off bonus to one of my team members, and rather went shopping for a nice gift with the same sum. One of them was purely a transaction, the other one was a gift.
So, not entirely nothing.