Fast and Hard Code

> All of a sudden I have seen people do some really impressive stuff with DWARF files, eBPF, custom network drivers, custom crypto and really old computing hardware. Many of these things were previously off-limits for lots of developers. In some cases (eg: crypto) you were even pushed away because those things were intentionally gatekept by the people in the know.

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.

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

What I got was, be more generalist and become a polymath.

My thoughts below

---

This means, we need to read more to produce more in many different fields, and domains.

The idea is also captured in today's top 10 article, "To become a better writer, read as much as you can" (https://news.ycombinator.com/item?id=49405870) where if you want to produce good writings, read more.

Reading more here means, familiarizing/learning/understanding many different fields/domains.

I have never heard of "DWARF files, eBPF," and at least reading gave me an idea on what to learn about, so that when I work on projects, I can consider them by guiding AIs to even consider them.

Until today, I'd never woulda have though to even consider "DWARF files, eBPF,".

Now I can dig deeper into them and see what they are, and at least know what they used for and how they are used in practice.

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

I do not know where things will go but here are some things I have been feeling:

- We have tons of languages (and libraries/frameworks on top) because we, humans, have too many preferences

- Many of these preferences are also abstractions because of how quickly (and with less knowledge of the underlying systems) we wanted to build things

- LLMs can operate on most (any?) of these layers and the results we get depend on how much high level knowledge the operator has

- LLMs + agents are able to do more and more of the digging, experimenting and ranking of different paths on their own to select good paths

- As someone who is assisted by LLMs, I can focus on codifying my internal process into custom agent/harness while also building end-user software (build the shipyard while building ships)

- I can reach out to any language (I am one of those who do not know Rust deeply but use it all the time) or any part of the stack now

How do you check the code if you don't know the language?

I think this is true to an extent, but it really depends on how much information the LLM has on a topic.

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.

For the "harder tech" part: I played around with a "vibe code" project to see how far it gets. It's a cargo workspace linter that does things like find unused feature flags, unused pub, etc. Guiding it only on high-level feature-set requirements, it ended up doing workspace-wide lints backed by rustc's name resolution, not a parser. Something I would never have done myself. I picked that project because a missed lint costs nothing - I still wouldn't work this way on anything where a wrong answer hurts - yet.

I have difficulty grasping how one would call a software project theirs, without understanding the meat of how it's put together & how it works. Or having done a good chunk of the grunt work.

Without such understanding, how is it 'your' project? Simply because you started it? Your taste / selection of design choices? Your "grand vision"? Your work in setting up some coding agent(s)? The prompt(s) you devised?

Ideas are cheap. But good software comes from good understanding of the problem. Good understanding comes from analyzing the issues in detail. Knowing the trade-offs between different solutions. All of which is not cheap. It is that expertise & experience which earns experts their paycheck.

When you did that, then sure, go ahead & have coding agents implement using a structure you designed, algorithms you picked, reviewing the code and test results. But just vibe-code a whole project & kick it out the door? Result might work but I'd be more impressed by the coding agents' capabilities than your input.

Article does give a nice hint about how the software landscape may change:

"Many of these things were previously off-limits for lots of developers (..) So maybe the world will have more slop, but it might also have more developers in it, that want things to be fast and small."

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, …)

> One of the memes on Twitter is that “programming is solved now.” I’m not sure to what degree it is, but one thing is pretty clear: the act of familiarizing yourself with a language no longer matters and some of the friction that mattered for humans does not matter for agents.

>

> As a result, LLMs make language choice much less consequential than it used to be. If you don’t like the choice, you can seemingly rewrite it in another language and you can make it pick a language that you, as a programmer, are entirely unfamiliar with.

...

> I’m not sure to what degree it (programming) is (solved.)

> the act of familiarizing yourself with a language no longer matters

> LLMs make language choice much less consequential than it used to be.

...

You're reasoning as if you think it's mostly solved. How the hell are you going to read the code with any reliability or speed if you aren't familiar with the language? I realize languages have broad similarities.

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

as a test of the proposition that human oriented software languages are redundant, I asked my favourite agent to rewrite some code in asm … and yes, it ran and it was fast

conclusion… well, it’s scary but actually I think it’s a bit useless too … it’ll never catch on

> the act of familiarizing yourself with a language no longer matters

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.

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.

[flagged]

[dead]

[dead]

[dead]