Size is not a good indicator for content quality

They are showing this new version scoring significantly higher across multiple coding benchmarks, beating Sol 5.6 (6.1 is the latest) across 10/11 benchmarks.

I am going back to DeepSeek for writing code. I was trying out using Sol and liking the result, but this should close a lot of that gap. I use Opus/Sol for an implementation plan and code review also use them for grilling. DeepSeek is also running verifications.

But, it may be that the performance of some roles is constrained such that the physical shape or rate and breadth of knowledge utilized isn't advantaged by the benefits of digitalized intelligence, and so would be approximately acting just human anyways. And in that case there may be enough human's available to do it just because they want to, fully fulfilling the demand for it.

I have found that agents are good at writing Verus proofs in a Rust code base, and that these proofs have only a minimal negative effect on the normal compilation path. I have a skill for using Verus: https://github.com/gregwebs/skills-sdlc/blob/main/skills/rus...

One of my spare time projects is a "prompted" 3D modeling app that is now (incl sub-crates I maintain) about 500k lines of Rust.

The link stage is the longest. An incremental build (w. sccache+mold) where I changed a few source files is done and runs after maybe 20s max on my 2022 Rhyzen 6800H-powered laptop.

I think this is acceptable when working on that kind of project.

For games where this matters I usually prototype in some other language first, TS, Python, Lua, whatever then translate to Rust when game mechanics and magic numbers are settled.

Or you simply put those into a config file that gets watched by the game.

At work we have an image manipulation crate that takes like 30mins to 'dev' and about an hour to 'release' build.

The WASM version takes even longer, about 2h, and needs like 55GB RAM during build.

But that crate has only to be built once a month.

And if it mattered we could split it because it's a metacrate made of ~20 sub-crates.

Yeah, it would be nice if Rust were even faster (I remember compile times almost a decade ago, when I started using it)!

But I think for the typical use cases where you would (should!) reach for it, it's quite ok already.

And if not you can work around it quite painlessly.

Isn't that the point of agents?

The average feature I spec and have an agent implement takes an hour or two (Either Opus 5.5 or DeepSeek 4.1 Flash, both at high and using subagents).

In-between the agents do not build that often because that is instructed in my setup.

They build maybe every 20mins when the target is Rust.

Ofc the models do not work like this by default. In fact they want to build all the time.

But as always, you need to tune the harness/setup for what you're using.

IMHO: if you use these models with Rust w/o those constraints/instructions "you're holding it wrong".

[0] https://mojolang.org/

[1] https://en.wikipedia.org/wiki/Chris_Lattner

I’ve switched one of my projects to Go and it took a day for Opus to do the port and another couple of days to finish the features I wanted. I’ve never liked the language and still use Rust in plenty of places, but I can’t argue with how much faster iteration is.

Ask your agent to build a simple bash/zsh/whatever cargo wrapper that maintains a machine build lock.

It should exclude cargo check, tree etc. ofc.

CPU contention from parallel cargo runs absolutely kills (build) performance.

Also my setup has instructions that agents keep working if they have open items while the lock is taken; i.e. launch a subagent or a shell with a watcher to run the build and don't block on it.

This makes all the difference when you have multiple agents on multiple workstreams on the same machine and they target Rust.

If you can direct AI and produce more value per $/time spent then a non software engineer directing AI to develop software then you still can produce a lot of value. This should be the case now for most things that are not a prototype. The job has changed from "writing code" to "shipping software". A technical lead.

Software products making ever more intelligent AI software development accessible will continue to reduce the need for software engineer involvement. But there’s also going to be 1000x more software. So there may continue to be opportunities for those that adapt.

This should be the case now for anything that is not a prototype. The job has changed from "writing code" to "shipping software". A technical lead.

As AI gets more intelligent and the tooling around it develops and organizations figure out how to get it access to the data, the level of involvement needed for software engineers will decrease. Since the cost of developing software is plummeting, the amount of software being used is going to expand greatly- that will keep the technical lead positions available longer and also create more opportunities for consultant engagements.

Although someone can use AI to rewrite every software dependency and every paid piece of software, its still not worthwhile for them for most software, especially if the price of the software is low compared to the complexity it hides.

Users of a paid software product still need a human to be responsible for it.

As you develop your skills with AI, you now have the ability to develop your own software products. So there's an opportunity to become a small business owner. You didn't want to do these non-technical roles, but now you can continue to direct AI to automate all the aspects of the business.

Sure, in the same way a skilled photographer can take better photographs on an iPhone than I can. Nevertheless, because any twit can take good enough photos on an iPhone, the need for the specialized skills of an expert photographer are much less than in, say, the 1930s.

That's why AI is dangerous. It's not because it makes human skill useless, it's because it makes non-human skill good enough. When was the last time you hired an expert photographer, or skilled dressmaker, or a master cabinetmaker? Maybe once or twice in your life, because the iPhone camera, fast fashion, and Ikea are good enough.

When no human knows what the machine is doing exactly, how do you know your intent is being followed? The seeming sufficiency of superficiality the public "enjoys" is an illusion needing upkeep.

Machines cannot make meaning, nor can they originate intent. They can't keep themselves suspended mid-air, detached from human understanding. You need engineers who understand human and machine, identifying the reasonable among the un-reflected wishes and making it explicit and precise.

No one is saying that no one will know what the computer is doing, but fewer people will have to. We are moving up the abstraction hierarchy, just as we have done since the stone age. In my grandparents' generation, knowing how to fix an internal combustion engine was a common skill among young men; today, it's been abstracted away. In the same way, I don't know how my clothes are manufactured, where my electricity is generated, or whether my CPU's "management engine" is spying on me. I don't need to know the details, because everything "just works." The same thing is happening with AI.

Without even looking it up, I expect that this is patently untrue. I bet way more people make a living as photographers today than in the 1930s.

EDIT: yep, about 4x as many today, and slightly more per capita even.

Not saying your overall point is off, but the fact that you picked a bad example is illustrative of a broader point: it’s very difficult to tell in advance how technology will impact employment.

EDIT: can’t reply so I’ll just add this here:

As I understood it, your entire point was that people don’t have as much need for photographers, dressmakers, and cabinetmakers today, because technology has given us low-skill or no-skill options that are good enough. Is that a fair characterization of your argument?

This is definitely true for some categories (agriculture, or elevator operators), but again, there are more professional photographers working today than in the 1930s. It wouldn’t surprise me if there are more seamstresses / tailors / etc too, more professional carpenters, etc.

Some of this is basic Jevon’s paradox in action, and some of it is just that median American is much wealthier (in real terms) than a century ago, so even though we can buy lots of “good enough”, there’s still a larger market for high-end skilled artisan labor than a century ago.

2. A photo is just what it appears to be. A program's code can't be gleaned from its output. Without checking the code you can't know if it's good enough or not.

3. For a lot of use cases, good enough isn't good enough. A good enough robot in a factory produces unacceptable defect rates, a good enough space rocket explodes way too often.

A highly dubious assertion. If demand for software is infinite, why don't we have infinite software, since we now have the ability to create infinite software?

> Without checking the code you can't know if it's good enough or not.

And even after checking the code, you still won't know if it's good enough, as evidenced by the large number of bugs that get shipped. I think it's clear that AI can do at least a good job checking code as humans can, so my argument stands.

> good enough isn't good enough

It seems like you are playing word games instead of addressing my argument. Can you please explain the point you were trying to make with this argument?

Even if true (which I'm leaning towards that it is), when will companies realize this?

We could be in for a decade long software career recession until the effects of poorly managed and written software trickles down to lost customers and company bankruptcies. Bad decisions in large companies take a very long time to produce clearly visible effects.

> As you develop your skills with AI, you now have the ability to develop your own software products.

I think this is a dead end. We're quickly approaching a state where software is no longer a product that can be sold, but rather a tool used by someone selling a service.

this does not mean software jobs would come back, you'd just end up in the amazon situation where today you use word made by JOXHSWW, then there are too many bugs and you buy another word made by ANSJJGG and so on.

Some B2B software will continue, but B2C can just become a single person fly by night with some models, or you can end up doing it yourself. A couple of years ago a model one-shotting a game of pacman was sci-fi, now it's just another benchmark, maybe the next model benchmarks will be one-shot photoshop or word or whatever. Either way today's C is more interested in doomscrolling tiktok on their phone than to booting up a computer to do some photo editing anyways.

As the article says, "taste" is still important in steering a model, but for how long? and how many people with taste do you really need compared to a few years ago where you needed people with taste AND a lot of people to execute.

It feels AI is just the next step of outsourcing, writing specs in the evening then magically the next morning software appears which might or might not work the way you expected, and the cycle repeated, only today the cycle is in your terminal and takes minutes vs hours/days

This makes the technical skills required but not sufficient part of the whole business and there are many businesses (like restaurants) that are bad businesses, because many people are willing to open a restaurant as a life-style choice even though most of them are not a good business. This influx of new competitors, make the current restaurant owners profit to go down, because of the increased competition that isn't purely market driven.

In the software world that means "a small product" won't have any moat & pricing power, and your competitors might be wiling to subsidise it for years as a side project, making the whole market suffer from profit erosion (an economic term) leading to zero profit long-term equilibrium.

For example try charging per message (as previously charged by SMS/MMS) in the era of subsidised messenger apps with free calls and messages.

This makes the unique position of SAAS software with 9$/month subscription highly doubtful in the future.

Most people stop after having gotten their dopamine hit. It was the case before, it's still the case now with AI.

Try any newly released software, and you'll notice a trove of issues, whether it's UX, UI, features not working properly. Errors, etc. All of the unsexy work that is needed to go from "it works" to "thousands / millions of people can rely on it daily".

Playing the long game has always worked, and will always work.

There are two ways forward for any company (whether big or small):

- Expand the pie: push AI to its limits while keeping your employees, new markets, new offerings

- Keep the same pie, and increase the size of the slices among the shareholders (employees or not)

For now, until the frontier models decide to stop losing money and pass the real costs onto the consumers.

The job of a programmer is now to be a technical lead and work through technical decisions with AI, write specs, and review work. But as AI gains intelligence and organizations figure out how to give it access to the information it needs, it will make better technical decisions than humans.

As long as a programmer can in some way produce more value/$ using AI then someone that doesn't know programming, then there's a huge value to programmers. But I don't see the place where AI can't go up the chain and do that itself as it gains more intelligence.

This is effectively true of any job that can be done at a computer. Although programming is one of the more difficult jobs its also one that is easy to train on. My advice if one's main goal is job security would be to do something in the physical world.

Woah, I gasped reading this. It is an extremely plausible future state of software development. Human written code can if fact be dangerous and sloppy compared to AI very soon.

Okay bit of nuance; this applies to fiction / nonfiction writing based on writing style, not so much correctness - for judging correctness you don't need to be good at writing code (or legalese, or fiction), but you need to understand what's written on the one hand and what the writing should express on the other.

I don't see how these are comparable. Let me re-word that statement with analogous disciplines: You could argue one doesn't need to be a chef to recognize good food, the same goes for building blueprints.

If it’s just about aesthetics or how it makes you feel, then yes I agree because how it made you feel is a signal of whether it’s good. Code is not like this, code is about accomplishing a specific function.

I don’t see how that’d make sense. Can you elaborate how exactly this will be the case, specifically about safety?

But it still doesn’t explain based on what principle and logic this is the case with regard to coding in a higher level language vs. assembly.

Let’s reframe the question: why do you think writing in assembly is less safe? Do the same reasons apply to AI coding? What are those reasons?

Don’t get me wrong, I think it’s good to let AI have a pass at the code, but this doesn’t lead to the above conclusion IMO.