Skip to main content


Just asked ChatGPT 5.0 about the design of a particular tool that I was curious to write in #perl, despite the fact that Perl is probably not the best tool for the job.

ChatGPT suggested I use the Inline::Python module.

Sigh.

#perl
Unknown parent

mastodon - Link to source
Curtis "Ovid" Poe (he/him)
@EndlessMason To be fair, when working with LLMs, Python far and away has the best toolchain orchestration support.
Unknown parent

mastodon - Link to source
Curtis "Ovid" Poe (he/him)
@EndlessMason When used appropriately, they are a hell of a lot more powerful than the naysayers claim. Vibe coding is terrible, but spec-driven development is amazing. Really amazing. Scary amazing. But it requires careful discipline.
Unknown parent

mastodon - Link to source
Curtis "Ovid" Poe (he/him)

@EndlessMason No. So far, I see it writing better code than most developers. And far, far faster. It's scary.

I have never said that about vibe coding.

in reply to Curtis "Ovid" Poe (he/him)

@EndlessMason Though I have to be clear, in addition to me having an EXCELLENT spec that I spent several hours on, it's also porting code from one language to another. That gives it a great start, so that's an important caveat.
in reply to seismo!allegra!utzoo

@SeismoAllegra @EndlessMason The title doesn't match, but here's a short video which is really important to remember. He skips a slide later in the talk, but it's a shame because it's an important slide. You should puse on it and read it.

I'm using github.com/github/spec-kit for this. This morning, I spent hours on the spec, and now I'm writing zero code and the code is solid.

in reply to Curtis "Ovid" Poe (he/him)

@SeismoAllegra @EndlessMason Again, it's very intimidating, but I also have a codebase I'm porting from, so that's also like an amazing spec, far better than what most people get, so I can't say how it will work on a brownfield project.
Unknown parent

mastodon - Link to source
Curtis "Ovid" Poe (he/him)

@EndlessMason @SeismoAllegra Part of my job is taking 225+ developers across multiple countries, languages (spoken and programming), and fixing their SDLC, making sure that from product idea to deployment, what comes out the end is what was asked for. Spec-driven development appears to actually do that.

But I don't have enough space to write out everything. There's a bit to learn and a lot to take in.

Unknown parent

mastodon - Link to source
Curtis "Ovid" Poe (he/him)
@EndlessMason @SeismoAllegra And to be clear, the knowledge *is* captured before the change because all of that goes into the spec that you have to create.
Unknown parent

mastodon - Link to source
Curtis "Ovid" Poe (he/him)
@EndlessMason @SeismoAllegra Also, I've already figured out a way to take a PRD (the "spec"), create the design, build the epics, add the jira tickets, all from this system. That knowledge all gets captured in one place, in the git repo, but can be shared with the common tools people use, like Jira.
in reply to seismo!allegra!utzoo

@SeismoAllegra @EndlessMason Oops. You probably watched the video in the github repo (which is great), but this video is more in-depth, though it specifically addresses the "context engineering" aspect of spec-driven development. Very good to watch.

youtube.com/watch?v=IS_y40zY-h…