> 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.
I disagree. Some of us love tinkering and learning and experimenting. AI can help with that. People like us will always do it. Hobbyist will continue to innovate even if others don’t.
>I disagree. Some of us love tinkering and learning and experimenting.
Which means that instead of millions forced to learn and get good as part of their job, it would be a much smaller percentage of "hobbyists who love to tinker" doing it.
And even that tinkerer subset would be smaller than before in the future, since now many that would have turned into tinkerers would be tempted to just use AI, or never develop the taste and skills to be good tinkerers to begin with.
So what you wrote proves what the parent wrote, and is not an argument against it. You're basically saying "huge problem isn't a problem because there will always be some small number of people it won't affect".
> Which means that instead of millions forced to learn and get good as part of their job, it would be a much smaller percentage of "hobbyists who love to tinker" doing it.
Plus a growing number of completely new jobs dedicated to research and exploring new directions in software. Just think about another technology that was revolutionary when it appeared: automobiles. At first, you (or your driver) pretty much had to be a mechanic, a metalworker and a "tinkerer" to maintain the car; but the majority of people just need a car to take them from one place to another. But research and development of new automotive technologies didn't stop, on the contrary.
Or everyone will find AI development incredible boring over time because everything already exists and is easy to make and will turn to going deep into their own hobby because of it.
I don't think we really know the second and third order effects here.
> everyone will find AI development incredible boring over time
A lot of us already does. Some people feel that they enjoy it because they already enjoy creating via programming from past experience. But these people, while they get to create more, I think they actually enjoy doing it less. And overtime, they will actually do it less and less until there is no "Wow AI did it" factor wears off...
I think we know from how Internet changed things. Internet actually made it a lot easier to do stuff without actually understanding things. Even before Internet computer magazines contained code listings that you can type into the computer to "make" stuff. I never did that because I did not enjoy it because it took the joy out of figuring out it on your own. From this experience I know that just making it happen, is not the thing that gives the greater joy. And without that greater joy, without crossing that threshold, one is not going to keep coming back to it.
>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.
Good, you achieved a 10% speedup for a particular workload that some users said they care about. But how do you find out that was really the feature that should have been built next? How do you prevent adding badly factored code? How to make sure you don't pile on top of existing tech debt in the codebase, that you are solving the most fundamental issues first?
I disagree, some people lie in wait, hoping for a really good problem to tackle because they just want the excuse to dig.
Do you think Linus needs to write any code anymore? What kind of problems do you think a guy like Linus chooses to work on, the easy ones or the hard ones?
Tools change, people stay the same. Some people have never felt the rush of solving a really hard problem that no one else was able to solve. Such people can't understand that the fun is in the work not just the outcome. They can't understand that some people love to work. And for a person who loves to work, new tools are a joy.
I don't love it, but I have to acknowledge that a frontier model building a feature that uses cryptography is going to have a better track record than the median human developer. The immediate practical problem with cryptography engineering has always been that there's a huge amount of detail you need to understand in order to get something right, but only a little bit to know to get something working. LLMs know all the details. They take shortcuts, but fuckups in mainstream cryptography features aren't really about shortcuts, they're about knowledge.
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.
That's not really the point of the saying though. The point is more so that if you are the kind of person who is in a position to roll your own crypto you probably have a PhD and have worked with cryptography for years. And the thing that you're setting out to do is to produce a cryptography library.
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.
I don’t get it. AI can apparently do anything, build entire massive applications in a day… except roll crypto, which has tons of papers, books and prior art to train on.
They did. And it was broken. And we iterated like crazy with people devoting their lives to studying the incredibly advanced mathematics underpinning modern cryptography. But please, roll your own using an LLM and show us all how wrong we are :)
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.
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.
> 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 of 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).
The author and his cited examples are folks with decades of experience shipping broadly used OSS so for them it’s probably a lot less of an issue to switch languages, even if the agent is papering over a lot of the details for them in the initial releases.
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.
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.
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.
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.
Thanks that’s an interesting anecdote to me because I’m also developing SwiftUI apps. Claude will create something that technically works but looks terrible.
I don’t have the luxury of a previously well designed app to train Claude on, but I’m finding just building the UI the old fashioned way then asking Claude to fix the bugs works to an extent.
I’m hoping that creating a comprehensive design system with good semantic naming will help.
That's a lot more than just visual design, as it incorporates things like branding and interaction.
You can keep iterating it, until you have something that works. It can be a fair bit of work, but worth it. In my case, I uploaded final PNG screenshots, along with detailed README files, explaining each screen. I also uploaded MOV files.
I use ChatGPT, which has a "memory," so I just declare the current state as "baseline," and it will always riff off of the design language. Not sure if Claude can do that.
Also, with SwiftUI, you have hard limits on what you can do, visually. I tend to use UIKit for my release products, because of that. I find UIKit to be a pain, but with it, and Autolayout, I can do almost anything.
I don't even know any more. I wanted a weather bapp that shows the whole forecast on one page with no scrolling, so I was ambitious and asked anti-gravity to build one for me. Half an hour later, done. Then I asked codex to review it and half the stuff didn't even work, made up wind gust data, misaligned hourly data, polluted caches. So I asked codex to fix the issues. Did it? I don't even know, it said it did.
The way to use AI is to make sure it has clear, verifiable success criteria, test suites, etc. Make sure any output has citations, reduce the need for trust to zero, etc.
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.
Claude Code more or less does have the tools to do this: plan mode, todo lists, user question prompts, et al. What it does not have is a "guided" mode where the agent (or harness) interviews you and helps you structure a work plan for the agent, including eliciting those success criteria and any design constraints the user might have in mind (eg it will be used on a boat over slow satellite connection). I can't speak for OpenAI but I get the impression that Anthropic think of these things as opt-in power user features, perhaps on the premise that their LLMs alone are "smart enough".
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.
When it's your own codebase that you know intimately, you obviously don't want it polluted, and you want to continue to understand everything that's there. For rewriting things you understand perfectly, or porting code to different platforms, the LLMs truly are a force multiplier. But that's so different from the way they are used on new projects. Letting them make design decisions is the problem. To make design decisions, you have to understand the system as a whole.
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.
When I first started learning game engines there were a lot of "understend a game engine by building one" courses in various forms, and a lot of open source projects (plus the closed source/never published ones I don't know about) that where the implementation of an engine or a kernel or a database based on a known book on the field. So it's at least not entirely a result of agentic coding and AI in general, even tho it probably incentivized the phenomenon
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
> 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.
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."
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.
> 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.
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
> 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.
> now we will never have better stuff.
I disagree. Some of us love tinkering and learning and experimenting. AI can help with that. People like us will always do it. Hobbyist will continue to innovate even if others don’t.
>I disagree. Some of us love tinkering and learning and experimenting.
Which means that instead of millions forced to learn and get good as part of their job, it would be a much smaller percentage of "hobbyists who love to tinker" doing it.
And even that tinkerer subset would be smaller than before in the future, since now many that would have turned into tinkerers would be tempted to just use AI, or never develop the taste and skills to be good tinkerers to begin with.
So what you wrote proves what the parent wrote, and is not an argument against it. You're basically saying "huge problem isn't a problem because there will always be some small number of people it won't affect".
> Which means that instead of millions forced to learn and get good as part of their job, it would be a much smaller percentage of "hobbyists who love to tinker" doing it.
Plus a growing number of completely new jobs dedicated to research and exploring new directions in software. Just think about another technology that was revolutionary when it appeared: automobiles. At first, you (or your driver) pretty much had to be a mechanic, a metalworker and a "tinkerer" to maintain the car; but the majority of people just need a car to take them from one place to another. But research and development of new automotive technologies didn't stop, on the contrary.
Or everyone will find AI development incredible boring over time because everything already exists and is easy to make and will turn to going deep into their own hobby because of it.
I don't think we really know the second and third order effects here.
> everyone will find AI development incredible boring over time
A lot of us already does. Some people feel that they enjoy it because they already enjoy creating via programming from past experience. But these people, while they get to create more, I think they actually enjoy doing it less. And overtime, they will actually do it less and less until there is no "Wow AI did it" factor wears off...
I think we know from how Internet changed things. Internet actually made it a lot easier to do stuff without actually understanding things. Even before Internet computer magazines contained code listings that you can type into the computer to "make" stuff. I never did that because I did not enjoy it because it took the joy out of figuring out it on your own. From this experience I know that just making it happen, is not the thing that gives the greater joy. And without that greater joy, without crossing that threshold, one is not going to keep coming back to it.
I know this with near certainty.
I hope you are right.
>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.
I'm not saying you're entirely wrong, but LLMs can actually be a way to create even better things than those better things. I've seen it in action.
How do you judge "better" if you don't understand the LLM output?
By quantifying the result.
What are you talking about?
You want to solve a family of problems using some tool. You measure the relevant solutions performance metrics.
Now, you or someone else vibe-coded a new tool. You created new solutions and measure again.
You have just quantified the result of using the new tool.
How do you measure them if you don't understand what you're doing? A shitty benchmark or small test suite is not how solid software gets made.
You measure results, you benchmark what you care about. It works often enough to be useful
Good, you achieved a 10% speedup for a particular workload that some users said they care about. But how do you find out that was really the feature that should have been built next? How do you prevent adding badly factored code? How to make sure you don't pile on top of existing tech debt in the codebase, that you are solving the most fundamental issues first?
> some users said they care about
But how could they possibly know what they should care about if they don't understand the code?
> how do you find out that was really the feature that should have been built next?
Phew right they don't know. Only the devs understand what software should do.
I actually explained well enough why this requires to a large degree a competent developer to judge.
Before: millions of web programmers and only an elite few that dug all the way down to metal
After: millions of vibe coders and only an elite few that dig all the way down to metal
I'm not sure the world will be all that different. The people who want to dig will still exist, they'll just be using excavators instead of shovels.
Source: https://x.com/mark_k/status/2090842540870074806
No one wants to dig for diggings sake. bad example.
I disagree, some people lie in wait, hoping for a really good problem to tackle because they just want the excuse to dig.
Do you think Linus needs to write any code anymore? What kind of problems do you think a guy like Linus chooses to work on, the easy ones or the hard ones?
Tools change, people stay the same. Some people have never felt the rush of solving a really hard problem that no one else was able to solve. Such people can't understand that the fun is in the work not just the outcome. They can't understand that some people love to work. And for a person who loves to work, new tools are a joy.
>who loves to work, new tools are a joy
Not if the tool takes the joy out of work, and no one get a chance to learn that it is possible to have joy in the work...
[dead]
This sounds like you don't like to dig for digging's sake and are projecting.
we are on "hacker news"
in a long forgotten past, this used to be the crowd that digged.
As someone not in the know about cryptography, I know just enought that the words "custom cryptography" scare the hell out of me.
I don't love it, but I have to acknowledge that a frontier model building a feature that uses cryptography is going to have a better track record than the median human developer. The immediate practical problem with cryptography engineering has always been that there's a huge amount of detail you need to understand in order to get something right, but only a little bit to know to get something working. LLMs know all the details. They take shortcuts, but fuckups in mainstream cryptography features aren't really about shortcuts, they're about knowledge.
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.
> building a feature that uses cryptography is going to have a better track record than the median human developer.
Let’s say that’s true. That doesn’t mean that we won’t have a higher percentage of bad implementations because more people are rolling their own.
Like I said, I don't love it.
I'm not clear why someone would roll their own crypto. There are so many good solutions out there that are free that it seems pointless.
I keep hearing about post-quantum being an issue though.
It's time to get over the "never roll your own crypto!" bs.
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.
Everybody can device an encryption algorithm that they can't break themselves. That is not sufficient.
yeah, but imagine every message has custom (but flawed) encryption… security by infinite obfuscation
"Dropbox is like a thin bash script around rsync" vibe here
Please continue believing this so I can make more money by hacking your products.
They don’t though. LLMs are massive cheaters when it comes to unit tests. Claude will just conveniently not write tests for things it knows will fail.
Please tell me this is sarcasm...
Lmao, please go do that and get back to me. The Dunning Krueger in this day and age is alarming.
If no one rolled their own crypto then there would be none.
"Don't roll your own crypto." sounds a lot like "Don't you worry about crypto. Let _me_ worry about crypto."
That's not really the point of the saying though. The point is more so that if you are the kind of person who is in a position to roll your own crypto you probably have a PhD and have worked with cryptography for years. And the thing that you're setting out to do is to produce a cryptography library.
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.
I don’t get it. AI can apparently do anything, build entire massive applications in a day… except roll crypto, which has tons of papers, books and prior art to train on.
[dead]
They did. And it was broken. And we iterated like crazy with people devoting their lives to studying the incredibly advanced mathematics underpinning modern cryptography. But please, roll your own using an LLM and show us all how wrong we are :)
The point is that crypto is hard.
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.
The necessary computer science, you could probably implement. The necessary computer engineering, however...
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 of 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).
The author and his cited examples are folks with decades of experience shipping broadly used OSS so for them it’s probably a lot less of an issue to switch languages, even if the agent is papering over a lot of the details for them in the initial releases.
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.
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.
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.
> 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.
Thanks that’s an interesting anecdote to me because I’m also developing SwiftUI apps. Claude will create something that technically works but looks terrible.
I don’t have the luxury of a previously well designed app to train Claude on, but I’m finding just building the UI the old fashioned way then asking Claude to fix the bugs works to an extent.
I’m hoping that creating a comprehensive design system with good semantic naming will help.
You can ask Claude to create a "design language."
That's a lot more than just visual design, as it incorporates things like branding and interaction.
You can keep iterating it, until you have something that works. It can be a fair bit of work, but worth it. In my case, I uploaded final PNG screenshots, along with detailed README files, explaining each screen. I also uploaded MOV files.
I use ChatGPT, which has a "memory," so I just declare the current state as "baseline," and it will always riff off of the design language. Not sure if Claude can do that.
Also, with SwiftUI, you have hard limits on what you can do, visually. I tend to use UIKit for my release products, because of that. I find UIKit to be a pain, but with it, and Autolayout, I can do almost anything.
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, …)
I don't even know any more. I wanted a weather bapp that shows the whole forecast on one page with no scrolling, so I was ambitious and asked anti-gravity to build one for me. Half an hour later, done. Then I asked codex to review it and half the stuff didn't even work, made up wind gust data, misaligned hourly data, polluted caches. So I asked codex to fix the issues. Did it? I don't even know, it said it did.
The way to use AI is to make sure it has clear, verifiable success criteria, test suites, etc. Make sure any output has citations, reduce the need for trust to zero, etc.
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.
Claude Code more or less does have the tools to do this: plan mode, todo lists, user question prompts, et al. What it does not have is a "guided" mode where the agent (or harness) interviews you and helps you structure a work plan for the agent, including eliciting those success criteria and any design constraints the user might have in mind (eg it will be used on a boat over slow satellite connection). I can't speak for OpenAI but I get the impression that Anthropic think of these things as opt-in power user features, perhaps on the premise that their LLMs alone are "smart enough".
Try Fable and make it write a ton of tests. I generally don't trust benchmarks, as they don't match my experience, but this one[1] very much does.
[1] https://www.primeintellect.ai/research/nanogpt-speedrun
Great minds… that’s what I vibe coded with Claude couple of weeks ago.
> agentic coding
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.
When it's your own codebase that you know intimately, you obviously don't want it polluted, and you want to continue to understand everything that's there. For rewriting things you understand perfectly, or porting code to different platforms, the LLMs truly are a force multiplier. But that's so different from the way they are used on new projects. Letting them make design decisions is the problem. To make design decisions, you have to understand the system as a whole.
you can also situate the agent within your codebase and have it only write things you review (or have it not write/change the code at all)
> 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.
Sigh...
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!
Thanks for confirming Krei-se was right.
It's so inspiring to see high school students participating here!
Have a great day!
called it
When I first started learning game engines there were a lot of "understend a game engine by building one" courses in various forms, and a lot of open source projects (plus the closed source/never published ones I don't know about) that where the implementation of an engine or a kernel or a database based on a known book on the field. So it's at least not entirely a result of agentic coding and AI in general, even tho it probably incentivized the phenomenon
Is it really building your own if it's just rephrasing training data? Or is it license laundering?
People do the same. Everybody learns from what was there before and then added or changed things. No difference.
Do you really care if it works?
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
Fast and Hard - very much like Zapp Brannigan's love
> 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.
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."
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.
> 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.
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
I am confused. It succeeded at the task, why is the conclusion that it will never catch on ?
[flagged]
[dead]
[dead]
[dead]