AI is getting ridiculously productive

Yeah, that very much matches what I’ve been doing lately. Personal projects that I wanted to do for years but was always too busy or tired – now take days, and those are the complex ones. It took Claude a small 1h back-and-forth session with me to port my AstroNvim editor config straight to LazyVim; almost a one-shot. We cleared up a few visual preferences, added a plugin or three, I have then tested the setup in a brand new container, corrected just one small mistake – done. One hour.

So many things that were viewed as arcane knowledge or hard blockers can be done now, and in a way that does not rely on the AI agents after. One thing I want to also do is have a Manjaro (Arch-based) dev machine – and I already do – and have a script that syncs all its packages to Debian VM(s). Still working on it and it’s not done only because work is way too busy and I have too many other things going on so when I have 2 free hours in the entire day I’ll prefer spending them with family of course.

But yeah, we can and should move forward without too much fear. Obviously vibe-coding can and does do stupid and even harmful mistakes. “Git gud at prompting” is my response, though obviously not a panacea either.

Next step is for all of us to overcome our overprotectiveness of our own software and start doing a proper convergence because right now efforts are scattered in many areas. Historically speaking, 500k programmers all reaching 92% of X tasks is not good enough. We should start nailing stuff soon-ish.

But I don’t want to roleplay a guardian of the planet. Somebody else can initiate it. I am saying what I think should be the next leap. Convergence.

Imo this is the important portion here. Where you can have such guardrails and clear scope AI usage is really useful and productive. The less clear cases are where you do not have that.

I find myself just testing more directions now that they cost less. I can work with many parallel versions or even projects at once. Sometimes I find unexpected improvements that I would have passed right by otherwise. That results in real quality improvement.

Convergence within the computing world tend to come and go as I see it. For both better and worse. I still remember with anguish the time everything was converging on Java and C++.

I think we are still in the very baby stages of AI so I expect this is still in the rattling development tumbler for yet some time before it starts settling down. The daily experience of using various sides of AI is certainly getting better year by year. (Well, maybe with the exception of other’s invasive AI in places you don’t want it.

Official technical convergence can be a real innovation killer. There are ISO standards out there that has literally frozen technology at what was the best available in the early 1900s.

That is true. This was a very testable project.

A bit philosophically I’m not sure less clear always translates into worse though. It certainly does translate into more tokens use and time so there is that. Maybe I’ll call that an exploring phase.

I am making things work that I could not tackle myself. I can’t port algorithms to Nx but I can verify the outcomes. I would not put a week into foguring out how to build a vendor toolchain for some obscure GPU but it takes Claude an hour or two.

I have reworked a mmwave firmware project where I was just a bottle-neck and eventually just tooled up the build-upload-reconnect-evaluate loop so Claude could do it over MCP and it probably shipped 12 iterations before it nailed the issues but now I have the data flowing. Next we’ll start implementing more processing in Elixir.

some of this needs a lot of verification and QA on the results and it is proof-of-concept. But it also would not have been worth doing since it’d have taken me months to learn enough background to do it. Now I have spent a few days pushing three relatively ambitious efforts in the same angle forward.

It is wild. As long as they figure out the price/perfomance of these models I don’t see how our industry doesn’t change massively and weirdly. I am not necessarily enthusiastic about that but for the type of contract work I do disregarding this would be unwise.

That is exactly what I was thinking starting this very project. I’m clueless and lost at cutting edge statistics, but I know for sure what it should output and there are few sharp edges.

The verification stories seem to often lag behind the AI though.

I’ve been thinking about this article a lot lately. I think it’s correct.

I’m not surprised Elixir does well, and there are good reasons for that. But I am very surprised of of the Rust results. Rust has been working very well for me, with minimal need to churn over things. First run is usually working or very close and easily fixed. Maybe their tests were much larger or just unluckily different.

Strongly agree with these and similar sentiments in thread. This is my experience lately with Elixir, Rust, TypeScript, Python, D3.js… many examples of outcomes that would have been impractical for me to do on my own. Even counting the additional time I spend in planning and cleanup, I can do things in hours/days that would have taken weeks (or been skipped entirely).

Same here, I’ve been porting interferometry software from C++ to Elixir + Nx because as unable as I am to write those Nx parts myself, I have the optics knowledge, Elixir practice, and ability to use the original software to produce a golden master testing harness before tackling extraction, which makes guidance and verification of a robot’s work easy.

But as @dimitarvp raised, now that I have my alternative build (well, it’s concurrent and parallel whereas the original used singleton QT mode, so computer-wide single instance mode), I am trying to see how I could contribute to the original project instead with architecture or even UX ideas that my port demonstrates. Otherwise I am creating partial advancement and dispersion from the original, despite having actual people wanting to use my build (which covers the 10% I use of the original software).