Fast and Hard Code

As someone not in the know about cryptography, I know just enought that the words "custom cryptography" scare the hell out of me.

I'd say it depends.

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

> one thing is pretty clear: the act of familiarizing yourself with a language no longer matters

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).

Fast and Hard - very much like Zapp Brannigan's love

what i'm seeing is agentic coding helps be(come) more ambitious

build your own framework, database, operating system, game engine etc

things that used to be infeasible (too hard, too big, …)

Fine article, though it ended on a low note with the comment about cryptography engineers gatekeeping the technology.

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.

[dead]

[flagged]

[dead]