[stub for offtopicness]
How does it feel to see all your programming heroes turn into Linkedin-style influencers?
This is why you should never meet--nor listen too much--to your heroes.
Automatic Programming
131–140 of 257 posts
Re: Automatic Programming
#132I stopped reading at "soon to become the practice of writing software". That belief has no basis at this point and it's been demonstrated not only that AI doesn't improve coding but also that the costs associated are not sustainable.
Care to link your sources? At least one of the studies that got attention here was basically done with a bunch of programmers who had no prior experience with the tools.
Re: Automatic Programming
#133We maybe witnessing the last generation of master software artisans like antirez. This is beautiful to see, their mastery harnessing the power of the intelligent machine tools to design, understand and build. This is like seeing a master of image & light like michelangelo receiving a camera, photoshop and a printer. It's an exponential elevation of the art. But to become a master like michelangelo one had to dedicate…
> We maybe witnessing the last generation of master software artisans like antirez.
I'm told that chess is more popular than ever, despite it being decades since a human could dream of beating a top computer at it.
Re: Automatic Programming
#134Re: Automatic Programming
#135I have 30+ years of industry experience and I've been leaning heavily into spec driven development at work and it is a game changer. I love programming and now I get to program at one level higher: the spec. I spend hours on a spec, working with Claude Code to first generate and iterate on all the requirements, going over the requirements using self-reviews in Claude first using Opus 4.5 and then CoPilot using GPT-5.…
My experience is that such one-shotted projects never survive the collision with reality. Even with extremely detailed specs, the end result will not be what people had in mind, because human minds cannot fully anticipate the complexity of software, and all the edge cases it needs to handle. "Oh, I didn't think that this scheduled alarm is super annoying, I'd actually expect this other alarm to supersede it. It's gre…
I've been doing spec-driven development for the past 2 months, and it's been a game changer (especially with Opus 4.5).
Writing a spec is akin to "working backwards" (or future backwards thinking, if you like) -- this is the outcome I want, how do I get there?
The process of writing the spec actually exposes the edge cases I didn't think of. It's very much in the same vein as "writing as a tool of thought". Just getting your thoughts and ideas onto a text file can be a powerful thing. Opus 4.5 is amazing at pointing out the blind spots and inconsistencies in a spec. The spec generator that I use also does some reasoning checks and adds property-based test generation (Python Hypothesis -- similar to Haskell's Quickcheck), which anchors the generated code to reality.
Also, I took to heart Grant Slatton's "Write everything twice" [1] heuristic -- write your code once, solve the problem, then stash it in a branch and write the code all over again.
> Slatton: A piece of advice I've given junior engineers is to write everything twice. Solve the problem. Stash your code onto a branch. Then write all the code again. I discovered this method by accident after the laptop containing a few days of work died. Rewriting the solution only took 25% the time as the initial implementation, and the result was much better. So you get maybe 2x higher quality code for 1.25x the time — this trade is usually a good one to make on projects you'll have to maintain for a long time.
This is effective because initial mental models of a new problem are usually wrong.
With a spec, I can get a version 1 out quickly and (mostly) correctly, poke around, and then see what I'm missing. Need a new feature? I tell the Opus to first update the spec then code it.
And here's the thing -- if you don't like version 1 of your code, throw it away but keep the spec (those are your learnings and insights). Then generate a version 2 free of any sunk-cost bias, which, as humans, we're terrible at resisting.
Spec-driven development lets you "write everything twice" (throwaway prototypes) faster, which improves the quality of your insights into the actual problem. I find this technique lets me 2x the quality of my code, through sheer mental model updating.
And this applies not just to coding, but most knowledge work, including certain kinds of scientific research (s/code/LaTeX/).
Re: Automatic Programming
#136Earlier quoted context omitted.
How does it feel to see all your programming heroes turn into Linkedin-style influencers?
I don't see Carmack or Torvalds doing this, so it's all good (for now).
How big of a Carmack fan are you really, if you don't know one of his most well known takes on programming? (And you definitely don't need to be a fan.) Carmack has been heavily in favor of leveraging power tools since way back.
Direct quote from the man himself:
> I will engage with what I think your gripe is — AI tooling trivializing the skillsets of programmers, artists, and designers.
> My first games involved hand assembling machine code and turning graph paper characters into hex digits. Software progress has made that work as irrelevant as chariot wheel maintenance.
> Building power tools is central to all the progress in computers.
> Game engines have radically expanded the range of people involved in game dev, even as they deemphasized the importance of much of my beloved system engineering.
> AI tools will allow the best to reach even greater heights, while enabling smaller teams to accomplish more, and bring in some completely new creator demographics.
> Yes, we will get to a world where you can get an interactive game (or novel, or movie) out of a prompt, but there will be far better exemplars of the medium still created by dedicated teams of passionate developers.
> The world will be vastly wealthier in terms of the content available at any given cost.
Re: Automatic Programming
#137I think Antirez is gonna change his tune about this as soon as OpenAI et.al. start requesting royalties from software you built using their AI.
Re: Automatic Programming
#138Earlier quoted context omitted.
Prompting the AI is indeed “do[ing] it yourself”. There’s nobody else here, and this code is original and never existed before, and would not exist here and now if I hadn’t prompted this machine.
Sure. But the sentence "I am a programmer" doesn't fit with prompting, just as much as me prompting for a drawing that resembles something doesn't make me a painter.
So, what's your take on Andy Warhol, or sampling in music?
Re: Automatic Programming
#139We maybe witnessing the last generation of master software artisans like antirez. This is beautiful to see, their mastery harnessing the power of the intelligent machine tools to design, understand and build. This is like seeing a master of image & light like michelangelo receiving a camera, photoshop and a printer. It's an exponential elevation of the art. But to become a master like michelangelo one had to dedicate…
Well said. I think you see where things are going clearer than most here.
Re: Automatic Programming
#140I think Antirez is gonna change his tune about this as soon as OpenAI et.al. start requesting royalties from software you built using their AI.
I think he would too, but they’re obviously not going to do that.