> seeing feedback on your design in minutes rather than weeks or even months.
Weeks and month for to wait for a feedback in developing software? Are you the sloth in zootopia?
The longest cycle for feedback for me has only been hours. And that was about redesigning the core architecture of an app. Otherwise, it’s like 10 minutes cycle if it’s edit-compile-run, 5 minutes if it’s REPL (lisp, bash, python,…).
> If you told me five years ago that AI would eventually be generating novel math proofs, I probably would’ve said that it’s not happening in my lifetime. And yet here we are.
A single PC can solve a very complex simulation model in seconds, something that would require years using humans to do. Same as solving a very complicated maze. So if coupling a text generator with a proof verifier is now capable of coming up with a proof, I’m not particularly surprised. But given the cost, and the actual usefulness of the proof, I’m not particularly excited either.
But code is not a closed system, even if we do prove a lot of the internal mechanism, we still can’t know the input (noise), and whether the axiomatic foundation will hold. That’s the reason people don’t bother. The theory of computation is just too loose in its constraints. You just write enough tests to catch egregious errors.
"Software" might not be, and definitely not software systems -- but code can have each part of it atomically proven to be correct, assuming you test it with a sufficiently complex simulation model (which you've already granted is within the possibilities for LLMs).
Prove all the code in the software system correct, then prove their interactions are correct, and you've achieved your goal.
(I won't claim this is inevitable with the current tools, but it's at least within the realm of possibility)
> For example, languages that allow pointer arithmetic, unchecked array access, or use-after-free have huge opportunities to make security errors
All languages are built on top of an ISA, whether directly (assembler), or by mapping it to an abstract machine. The you have the dreaded “eval” function. Then because a lot of software lives on top of an OS, there’s all the virtualization that is going on (timesharing, virtual memory, filesystems,…). Memory safety is nice, but it doesn’t help you when the attacker send valid, but malicious data from a compromised source, or by exploiting a logic error.
And for kernel code, where everything is accessible to everyone, it’s much a matter of discipline, especially with so much hardware interrupts and syscalls from userspace going around. Most kernel code has very short lifecycle, it’s the data that is long lived, and it’s a shapeless blob in memory that you have to trust the other party kept in good shape.
> The director of my department kept asking, "But do we HAVE to do this now?",
If someone says that something is a risk and we should address it, I don't expect a director to ask for a specific date the risk to become a disaster. Instead, he should just add it to some todo list and slot some time to analyze it and and budget resources. AKA, doing some "management" work. You shouldn't have to explain his job. You didn't need to learn semiconductors physical properties to know that storage can fail and you need to do backup.
> Many people in the tech world seem to espouse a great love for "always learning", but the way in which it is said always feels funny to me. Learn about what? When people say this, do they mean that they want to always be learning the next programming language, the next web framework, the next thick-client frontend web framework, the next python packaging CLI tool (pypi, virtualenv, uv ...), the next Linux distro
For me it’s been: Learn more about unix through OpenBSD as a daily driver, learn how the usb and pci stack works in the kernel, refresh my knowledge about operating system, learn a simpler processor (avr) and interfacing, learn digital logic and computer organization, reignite my interest in electronics, refresh my knowledge about control systems, learn how to model dynamic systems, quick dive into robotics…
This is just basic curiosity over the last year. When I was younger and had more time, I explored 3D modeling, making games, pen-testing and reverse engineering, learning various software and platforms,…
This always reads like “writing english is solved” just because you collected snippets of famous works and have built a spell corrector.
Code is written to process data. The struggle was never to learn programming syntax (most grammar are only a few page long). The main struggle was that it’s hard to model a domain into an information system, identifying the components and their relationships, what is ingested, and what needs to be output.
Computers have integers and floats, but you need to implement units like distance, money, various counts,… The real world have words and sentences, but that needs encoding like ascii and unicode as well as the “string” concepts to make it work. Take HN, I’d bet that if you can model it in terms of data, writing code is not an issue.
Thank you, this is what I've been seeing. Structs and objects are easy, but the hard part is encoding the domain most accurately into given data types of the computer (or creating new data structures to solve the problem!)
If anything, I do expect the casual non-tech users to be making the most adaptable software because they have what they want in their head.
Although, part of what the dev does is figuring out the weeds, and only a part of users have the patience to sit through detail corrections. And the AI user has to verbalize their wants exactly too.
> I do expect the casual non-tech users to be making the most adaptable software because they have what they want in their head.
Those are the people who are most likely to give a monolithic prompt and then spend a week telling the machine 'I don't care about encryption or file permissions, just make it work.' Not to mention that most people can barely verbalize the problems they have with devices they use for 8hrs a day, let alone form a full, self consistant, project idea and then put it in writing.
if they're persistent and patient enough to see the result of what they think they want and iterate enough times they'll eventually learn. non-coders aren't dumb by default after all and I suspect they'll learn much faster than us because they won't be bogged down by the minutiae like reading docs.
Imagine you could build a piece of furniture without actually needing to know how to cut wood, drive nails etc. Imagine you could do it in 3d without knowing how to actually handle wood, you just have an image you can iterate on without actually costing you anything but time.
I remember the first big app I wrote in high-school. I had to learn C++, learn Qt etc. I knew what I wanted but putting that into code when I didn't know any of the libraries / tools was a huge time investment. If I had LLMs I could've done the same thing it took me 6+ months in probably less than a month.
> non-coders aren't dumb by default after all and I suspect they'll learn much faster than us because they won't be bogged down by the minutiae like reading docs.
They may have a perfectly good shot at being smart, but I still don't buy the argument. The reason they struggle to become coders (assuming they tried at all), in my experience, is a lack of problem-solving and debugging skills. There is no real shortcut here. An "image" of the chair isn't enough; when the first iteration is wrong, you have to be able to explain why it's wrong.
I think there are a lot of people out there with good problem-solving skills but for whatever reason did not get into programming or they tried and they got put off with learning the languages / libraries or got stuck and didn't find a solution easily enough and gave up etc.
With a sufficiently good LLM these people will skip the tedious part of programming that most of us had the motivation / patience to go through. All the folks saying that actually writing code wasn't the bottleneck have had a LOT of years to get to that point, years a lot of people aren't interested in going through.
I'm not saying lay people will be able to join mega projects and work at FAANG. I'm saying a sufficiently courageous lay person will be able to make an app to automate whatever tedious birocratic process their niche work hasn't seen a product yet.
I can absolutely believe this, actually. Considering how the access to rapid prototyping has rejuvenated my interest in programming when I am a seasoned programmer, I definitely see the value in that kind of jump-start.
And yeah, without LLMs, writing code absolutely can be the bottleneck sometimes, if only for psychological reasons. I've definitely experienced something like "coder's block" before. An anti-flow state, if you will.
(But skydhash is also right. The "unknown unknowns" are a big deal and there's only so much an LLM can do about that, at least unless the user is actively aware of the general shape of that problem and trying to learn via the LLM and fill in those knowledge gaps.)
> All the folks saying that actually writing code wasn't the bottleneck have had a LOT of years to get to that point, years a lot of people aren't interested in going through.
The years was not spent on learning how to code. The years was spent on learning about what needed to be coded. And that would have spanned multiple domains. Even the most basic production level software have multiple concepts that need to be integrated. And for that, they need to be learned.
Using AI without the requisite knowledge is playing Russian roulette. It’s kinda wanting to log into a file, and not thinking about disk storage being finite, and rotating the log file gives you flexibility. That’s not related to coding, it’s just hard thinking about the problem and the constraints (or finding a good book or article).
> Using AI without the requisite knowledge is playing Russian roulette
Every few months that revolver has a few more empty chambers and even if it shoots them in the foot, it can bandage them quite nicely. Will a solo lay person with an agent build a high quality high reliability software business? Doubtful. Will they be able to make a tool that helps them and 10 other people or a personal website? probably.
> Will a solo lay person with an agent build a high quality high reliability software business? Doubtful. Will they be able to make a tool that helps them and 10 other people or a personal website? probably.
Just take a quick look around to see how many daily tools and utilities are actually built by experts and industries. Yes, you can put a plank on top of two concrete blocks to make a bench, but many people don’t and prefer to have good bench made, even when it’s quite easy to DIY one.
So I don’t foresee lots of people trying to make custom tools, more so to keep a subscription active.
just because you have an idea doesn't mean it will work. kids come up with ideas all the time in their drawings, but they disobey the laws of physics and are therefore not feasible in reality. sure, the model can guide them, but eventually they would have to pick up the necessary knowledge.
The necessary knowledge needed with LLMs goes from needing to know programming languages and libraries to having a high level view of what is possible which is far easier and less boring to get
> Although, part of what the dev does is figuring out the weeds, and only a part of users have the patience to sit through detail corrections. And the AI user has to verbalize their wants exactly too.
Even with basic pseudocode and very lenient logical rules, most people won’t bother to provide a a good definition of some process, as it’s quite unnatural to be that logical. Instead, it’s mostly just playing around. When you ask the one that is supposedly 10x-ing his productivity to explain his mental model of their own projects, it’s often a wishlist instead of a real understanding of what he has built.
> The struggle was never to learn programming syntax
For 85-90% of devs, yes this was the struggle. Creating and updating rows in a database from user input is all the “domain modeling” there is in most software. That’s what is solved by AI and it’s the majority of software dev.
Learning syntax takes a weekend. Learning to approach problems analytically and algorithmically takes much longer, and is the only "hard part" of computer programming.
It takes a weekend for a software developer. For a totally novice it takes a lot more time
The issue here is that you are learning the syntax at the same time you are learning foreign concepts, and the syntax is often confusing and counter intuitive
Learning the syntax separately is of no use because without a mental model you can't do anything with it
I remember learning python in high school by following the tutorial in the official docs, then from a book. Up until function and OOP, it was fairly easy, but I gave up afterwards because the exercises touch on things I haven’t learned yet like trigonometric identity. I could see and understand the syntax, but I couldn’t understand the code.
This is why children can easily learn enough programming to create games, because it’s a domain they can comprehend easily. Just like they can use english to write about their daily lives. It will be simple sure, but it will work.
So learning to code is fairly easy, you can easily create simple programs after a weekend. More complex programs will still use most of the same basic concepts as far as coding goes, but you will need to master more complex concepts, and that takes time. And such concepts are not about coding, they are about the nature of computing or the domain the software is created for.
This is why experienced devs only need a few days doing kata to get up to speed with a new programming language. It’s usually the same old, with slight differences. What was always needed was an understanding of computing and the ability to break down problems and create a solution that can be computed.
Coding to me is the same as drafting an engineering schematics, or writing a sheet music. It’s just a tool, not the end result.
Those who think the challenge is to overreach the limitations imposed by programming languages and types, etc, to do seemingly "magical" things. These are ones who would never understand why you might want higher-kinded types, the relative pros and cons of the functional vs imperative approaches, or even of type systems in general. They also tend to think the code written, in itself, is the valuable output of their work.
And then there are those who think the challenges is to model problem domain so well, using the language features, types and data structures, etc, that the solution (and further adjustments to it) becomes obvious and straightforward. They also tend to think the analysis and model that results is what is valuable.
Another way to see this difference: what impresses them? it is a hack that uses arcane knowledge to bypass software and hardware "limitation" or structures? Or is it code that is simple but still effective at solving complex problems in elegant ways, that may look simple but reflects a huge amount of knowledge, skill, and architectural intuition built up over many years?
I of course think that the second group are more effective and are doing proper programming, but many programmers and the general public think otherwise, or can't event tell the difference. I once worked with some colleagues could never see the light, despite a lot of support from me.
So here is the kicker, the dissonance in response to AI, I think, is kind of analogous to these two groups. The first groups likes that the AI will not stop them, but rather get them much quicker to their "magic", whereas the second group is more skeptical and sees many issues with AI not seeing the big picture and understanding deeper intent.
It certainly wasn't "approaching problems analytically and algorithmically" that prevented me to contribute to many open source projects in the past.
On the other hand, I've made 3 apps in 3-days' spare time, which I could not find in years and were not worth investing months of effort at the time.
I don't think the education barrier fully accounts for SWE salaries. It takes a particular disposition and other hard things, learned over years of doing, to actually keep do software engineering as a career.
AI changes the dispositions and difficulties, but it still favors a narrow selection of people to do the (still) difficult task of software engineering with agents.
> since agents write everything, it is simple to propose sweeping changes to my teammates during code review, or even write my own versions — both things unthinkable in the era of hand-written code.
That is both untrue, and should be something that occurs rarely.
Past Mid level, most dicussion in code review is centered around the conceptual level. Code is mostly use to highlight the point being made. I’ve never seen the need for someone to rewrite a patch proposed by another person. Add to it or correct misunderstandings, but never sweeping changes.
As a vim and emacs user, macros are really nice. But the true superpower, IMO, is that code is fairly structural in the file and outside of it, and both allow me to quickly navigate that structure. Vim is more powerful on the edit side, but emacs has more convenient utilities.
> Does your manager at your job review every line of code you wrote or trust you based on your competence and reviews only a compressed portion?
The manager always has a very good stick: “Do a good job or you will be fired”. And me wanting food is well aligned to not produce buggy code. Or make my job harder in the future by writing unmaintainable code.
> Frankly, these discussions are tiring because there's a false notion that humans have to be in the loop 100% of the time
The code is written to process data. Someone needs to be aware of how it’s processed, so that when malformed data appears, we can collectively find where it happens. You can always play around with your own data (if regulation allows) but you need to respect your customers’ data. Not looking at the code jis just negligence.
> The manager always has a very good stick: “Do a good job or you will be fired”. And me wanting food is well aligned to not produce buggy code. Or make my job harder in the future by writing unmaintainable code.
You are welcome to not use the model if it makes mistakes. Its weird that you are cooking up some edge case scenario to make your argument strong - everyone is incentivised to make things work well. Anthropic wants their models to perform well because that's why you will buy it.
> Someone needs to be aware of how it’s processed, so that when malformed data appears
Eh no. You need to know about only a compressed part of it, not 100%. Do you really claim that you need to know 100% of the code? This is not true today and certainly won't be true in the future. Hardly any code will be looked at by humans in the same way my manager doesn't look at my code.
> Anthropic wants their models to perform well because that's why you will buy it.
What Anthropic wants and what happens in reality are two different things. But with code I write, I do control the process.
> Eh no. You need to know about only a compressed part of it, not 100%. Do you really claim that you need to know 100% of the code?
I know the code I write, and I know how it interfaces with external modules. When those interfaces don’t function as described, I look at the code if I have access to it. When I don’t, the party in control has always good incentives to produce good documentation. That knowledge is usually good for some time (years even)
> my manager doesn't look at my code
Because that’s not his responsibility, just like he’s not responsible for bugs and crashes. He’s responsible for the project and the team and you can be pretty sure that he’s looking at all at the information about those. Imagine if his own manager ask him about some details and he answers: “I don’t know, Claude is doing it”.
> Such a colossal volume of slop that even the most well engineered, efficient technology on the planet, written by one of the greatest coders of all time, is no longer sufficient to contain it.
And git is enough to version control some of the most complex software like the Linux Kernel, the FreeBSD operating system, QEMU, browsers like Firefox,... Git was insufficient for Facebook and Google because they wanted to put the whole org inside a single repo, which broke the assumption where decentralization in git would happen (repo level, not subtree level). Now it seems that another assumption is broken, that you wanted a version control system, not a snapshot or a rolling log.
Weeks and month for to wait for a feedback in developing software? Are you the sloth in zootopia?
The longest cycle for feedback for me has only been hours. And that was about redesigning the core architecture of an app. Otherwise, it’s like 10 minutes cycle if it’s edit-compile-run, 5 minutes if it’s REPL (lisp, bash, python,…).
reply