Fast and Hard Code
lucumr.pocoo.org
lucumr.pocoo.org
Before at least some of us were forced to understand stuff, because without understanding it was not possible to do stuff that we really wanted to do, and some those got passionate and kept digging, and some of us even made even better stuff based on their experience.
Now no one needs to understand anything, and now we will never have better stuff.
Even worsr in that those starting out during this time, wouldn't even understand enough to guide and evaluate the AI output, or even even to know what to ask for.
AI can roll you crypto far better than what humans have built by hand. They can literally test things to an extent that no human ever would.
"Don't roll your own crypto." sounds a lot like "Don't you worry about crypto. Let _me_ worry about crypto."
If you're that kind of person, then sure go for it! But if you're a top person in the field of cryptography you didn't need anyone to tell you if you were fit to make a cryptography library anyway.
And if you're not that kind of person you do need someone to tell you because the whole field is a minefield where subtle oversights break the whole thing. If you want to just implement cryptography as a fun learning experience that's great. But actual implementations that people will actually depend on need to be handled by experts.
Therefore many people need to check it, to ensure it is correct.
The crypto you rolled yourself is unlikely to have been extensively tested.
It's like alpha software. It may have no known bugs, but it hasn't been tested in the wild. Once it has been tested and the bugs fixed, because there will be bugs, you can release a stable version.
You shouldn't rely on alpha software for critical things, like keeping secrets, secret.
So yes, write a crypto algorithm, but don't represent it as working correctly if you don't know it is or force others to use it, and don't use crypto that hasn't been extensively tested.
I keep hearing about post-quantum being an issue though.
The most important thing to do with cryptography features is to stress test them ("spend $10 on verification for every $1 on implementation"), and that too has become a lot easier with frontier models.
On the degree the software evolves and will be used.
The reason we've spent years discovering patterns, creating special syntaxes has been to tackle certain domain problems more efficiently and to have systems that can evolve through time.
The only constant is change.
Albeit LLMs chunk out code (and with great know how impressive output), the developer must have the know how to pass a certain threshold.
Writing in unknown languages may seem fine at first. But once you go to the edge, you'll be finding certain quirks, inefficiencies along the way that the LLM may work around it instead of removing it from root.
For example, I've been learning Effect.ts for some weeks now. I've used LLMs extensively, but before that there were a series of manual coding rounds first.
To understand composability, the nitty gritty, where things break, how, how the syntax is formed, and how could I structure some observability challenges I had around the library.
If I hadn't gone through that process, the code quality would be subpar. It wouldn't have been evident at first, but once the system would begin to evolve and adapt to feedback, things would be brittle, existing customers would be affected, and more.
I like to move fast without breaking things
I completely disagree with this statement as a premise to the article.
Sure, if you have zero care about whether the agent's work is reliable or not, then there's no need to learn a language. But if you're a developer who cares about their work and isn't just outputting 100% vibe code, then at a minimum you should be familiar enough with the language that you can review the agent's output ,follow along with the code, and make an informed decision about whether to commit.
Interestingly, I've found that my approach to learning languages has fundamentally changed. Before, I'd study a book on the one or two languages which were important to me at that time. The goal was to become proficient. Now I choose to read about a variety languages simply because they demonstrate some interesting paradigm that is new to me (e.g. Haskell -> functional, Elixir -> concurrency). I read a programming book like I'd read an engaging narrative non-fiction book: cover to cover relatively quickly, then I'm done. This gives me that "familiarity" which is useful for agentic coding, without bothering to learn every obscure bit of syntax or library call. My priority has become breadth (get an overview of many languages and paradigms) rather than depth (learn a language or two really well).
I have worked on high stakes crypto code. Getting it right requires a level of knowledge, care and engineering conservativism that is very hard to come by. I was teaching students. I wasn't gatekeeping. But a vanishingly small percentage of them were able to make secure software, or analyze existing code to know if it was secure.
In as much as AI coding makes testing or code verification cheaper, sure let's use it. But cryptography engineering is hard for reasons that are not "write moar code" and so AI coding should not be used on production crypto work.
They’re amazing at maths because maths has been open source since day 0. They’ve great at algorithms for similar reasons. C bindings are a doddle because there’s so much prior art available. They’re terrible at using cutting edge features in languages because there’s not much data yet.
I think it’s fairly easy to predict what they’re good at on this basis. I’m not sure why they suck at UI design though.
I think they do OK, if you are fine with middle-of-the-road, default stuff. Also, I have found that it's important to provide guidance, constraints, and context to the LLM.
I have been working on a native iOS Swift app, for the last few months, and our team consulted an LLM (might be ChatGPT, might be Claude -I wasn't the one that consulted it), for graphic and interaction design.
Some context: We have written a 2.0/full rewrite of an existing app, that has been shipping for a couple of years. The 1.X version was designed by a professional graphic designer, but we didn't have him available for the rewrite, so we had to make do with our own guidance (questionable), and LLMs (also questionable, but for different reasons).
Anyway, As I started on the project, I kept getting designs that were, quite frankly, awful. They looked like generic Apple SwiftUI app screens, or worse, old Facebook app screens, with absolutely no relation to the current app. I had to basically ignore most of the graphic layout, and use only the interaction design.
After hearing complaints about "not making it look like the screens I sent you," I explained that they needed to train their LLM on the current design. There was no way that I was going to implement those ghastly graphics (It is so good to be able to do that. I'm retired, and working for free. In the old days, I would have had to take out a spoon, tuck in a bib, and eat shit).
They did that, and suddenly, their submissions were great, and I could start using them.
build your own framework, database, operating system, game engine etc
things that used to be infeasible (too hard, too big, …)
In my personal experience, agentic coding wasn’t useful, but using a chat inference, was. I still need to be the critical path, but the LLM has, indeed, become a major force multiplier.
A few minutes ago, I submitted an app for review, that I started work on, alone, in February. The Quality of the new version is astounding. I’m absolutely thrilled.
It’s a full rewrite (backend server, and frontend client) of a fairly large app that’s been shipping for a couple of years, and that took over two years, to originally write.
I wouldn’t have even tried it, without an LLM. That made all the difference. The majority of the work was done with the $20/month ChatGPT Plus subscription, but the last few days, as I developed supporting materials and Web sites, I used the $100/month Pro level. After my work, over the last few months, the upgrade was a “no brainer.”
But, at every step of the way, I needed to be there, to intimately review and manage the interaction with the LLM. There’s no way that I could trust it to “just do it.”
I’m sure that, sooner or later (likely sooner), LLMs will have progressed to the point that I can trust them to vibe-code a project like this, but I guarantee, that they aren’t quite there, yet.
To be fair, I know that I may have much higher standards than a fairly significant number of developers, but the end product of my work is about as far from “AI slop” as you can get.
as always: no code, no link, not even a description.
Incoming reasons: possible doxx, "internal", etc. pp.
Seriously? I've explained this many times, but I assume that doing background research before insulting isn't a "modern" thing to do. Just Ready, Fire, Aim. Seriously, you could probably use ChatGPT to make a decent guess.
The issue is that the app addresses a specific (very privacy-aware) demographic. Each signup is manually vetted by two admins. It will probably never have more than a couple of thousand users, and the ones that are there, are more than a little [justified] paranoid.
Having several thousand curious geeks, do throwaway signups, just so they can see that the app is not for them, is not going to be helpful, so I never mention it here. If anyone really wants to know about it, I'm easy to contact. Unlike lots of folks, here, I am quite open about who I am.
The app, itself, is closed-source, but uses a significant number of open-source dependencies (that I also wrote -sometimes with AI help), which are easy to see.
And that's all I'll say.
Have a great day!
Have a great day!
I see people one shot stuff and it makes no sense, is completely fake half the time, just like you point out.
It should be the case that Codex and Claude Code should incorporate this kind of thing automatically at some point.
Not so fast. I've seen all sorts of LLM-generated code that was not not inline with a what a human would write if such a human were familiar with the sharp edges of the language in question.