[eddieroger]

> If I know the answer to all these questions, wiring it together takes me LESS time than passing it to Claude Code.

That's just not true, and if it is in your case, then you're not great at writing prompts yet.

> Take the todo_items table in Postgres and build a Micronaut API based around it. The base URL should be /v1/todo_items. You can connect to Postgres with pguser:pgpass@1.2.3.4

That's about all it takes these days. Less lines of code than your average controller.

[majormajor]

Every day I do something where the llm writes it ten times faster than I would with twice the test coverage.

And every day I do something else where the LLM output is off enough that I end up spending the same amount of time on it as if I'd done it by hand. It wrote a nice race condition bug in a race I was trying to fix today, but it was pretty easy for me to spot at least.

And once a week or so I ask for something really ambitious that would save days or even weeks, but 90% of the time it's half-baked or goes in weird directions early and would leave the codebase a mess in a way that would make future changes trickier. These generally suggest that I don't understand the problem well enough yet.

But the interesting things are:

1) many of the things it saves 90% of the time on are saving 5+ hours

2) many of the things I have to rework only cost me 2+ hours

3) even the things that I throw away make it way faster to discover that 'oh, we don't understand this problem well enough yet to make the right decisions here yet' conclusion that it would be just starting out on that project without assistance

so I'm generally coming out well ahead.

[qingcharles]

This. There is definitely a ratio. A year ago, it was 50/50. It felt better because the hard things it did fast while I sipped coffee outweighed in my mind the negatives.

Now that ratio is swinging way over towards the LLMs favor.

[sarchertech]

>you’re not great at writing prompts yet

How do you reconcile that with your example prompt, which demonstrates no skill requirement whatsoever. It’s the first thing any developer would think of.

[vlunkr]

It’s simple but contains all the necessary info. You can say “build an endpoint to get user data” and it will absolutely do something, but it might be stupid, and when you compound 1000 stupid prompts like that you get spaghetti.

[eloisius]

It doesn’t contain any information at all about the structure of the JSON output. Is this a greenfield endpoint and anything will work is does it need to conform to an existing API? What about response codes for different failure modes? What about logging?

Your comment exemplifies what a lot of people complain about vibe coding: it works great for greenfielding CRUD apps, but it’s a bitch to use in a real code base.

[theshrike79]

If it's not a greenfield project, the Agent will go and look at the other endpoints and mimic the style as much as possible. Just like a human would.

"But we have documentati..." then give the Agent access to the same docs as humans and it'll use them.

[sarchertech]

On a real codebase there’s going to be v5 that is the newest version, v4 that we planned to migrate off of but we had to keep around for iOS clients, and v3 that no one except for a dozen huge enterprise customers use. But we need to support all 3 styles. This stuff is sort of documented, but not completely, and there’s a push by some people in the org to use v5 style for every new feature, but there’s one director pushing back on that. So you need to go talk to a few people and get enough condensed to CYA before deciding what to do.

Some version of that happens in every big company or every long running app. Claude isn’t AGI and that prompt isn’t nearly specific enough for anything outside of greenfield.

[theshrike79]

AI can't fix shit processes =)

I actually believe it just surfaces them, humans will tolerate ambiguity like that and deal with it. AI Agents either won't work properly or will just fail to do anything useful.

[sarchertech]

A programmer wouldn’t write a prompt like that. Notice the questions the OP talked about out answering first.

[apsurd]

I've drank the AI koolaid so I'm not a hater, but to say "you're just not prompting right" is such a cop-out. Prompting right takes a metric fuck ton of effort. I'm actually kinda agreeing with you, if you make it to where you're dev environment is sufficiently harnessed, then you can give it one-liner magic prompts. But getting there, learning to get there, paying that cost, hot mother of god it's a lot of effort.

Communicating, in words, is extremely hard. I don't think this should be as controversial as it's seems in the prompt era.

VS: someone has mastered one of the myriad openAPI generators, and it's shipped.

[phpnode]

it does take a little while to get good at this new skill, yes. Just like, say, learning a new programming language and the ecosystem around it takes some effort. After you get over the hump it's really very straightforward and mostly a matter of knowing the kinds of mistakes the LLM is likely to make ahead of time, and then kindly asking it to do something smarter. If you've successfully mentored junior engineers you already have this skill.

[apsurd]

that's well put. But i'd stress mentoring junior engineers is really a high effort, high leverage, high demand skill. A good teacher is gold. and not common.

[xmprt]

I'll go in the other direction and say that if you're spending a lot of your time learning to prompt better then you're wasting it because LLMs are only going to get better at understanding your intent regardless of "prompt engineering". The JSON API example to wire up a database can be one-shot pretty easily by the latest models without much context and without setting up any harness. The more time you spend perfecting your harness, the more time you would have wasted when the next model comes out to make it obsolete.

[majormajor]

The hardest thing about software engineering has always been that your intent often has to be decided on the fly once you get into complicated edge cases, weird-or-legacy-business requirements, or things that the spec literally has no answers for.

Letting the tool figure out your assumed intent on those things is a double-edged sword. Better than you never even thinking of them. But potentially either subtle broken contracts that test coverage missed (since nobody has full combinatoric coverage, or the patience to run it) or just further steps into a messy codebase that will cost ever-more tokens to change safely.

[derangedHorse]

I was thinking of this interpretation as I read that:

"I'll go in the other direction and say that if you're spending a lot of your time learning to [program] better then you're wasting it because [computer]s are only going to get better at [computing] regardless of "[software] engineering". The JSON API example to wire up a database can be [run] pretty easily by the latest [computer]s without much [design] and without setting up any [optimizations]. The more time you spend perfecting your [program], the more time you would have wasted when the next [computer] comes out to make it obsolete."

[apsurd]

but then how can the parent comment land? "you're just not prompting right"

[xmprt]

I don't think it does. If I had to guess, the top comment was using an older version of AI or a local model which wouldn't be able to solve the JSON API task. A lot of AI skepticism comes from people who used it once a while back and decided not to keep up with the latest developments. If I only had experience with gpt-3.5 then I'd also assume what the original commenter said.

[majormajor]

An experiment I'd love to do, but which isn't actually possible anymore, is run GPT 3.5 or the original 4 API release through a modern "agentic" harness for a task like this.

I think 3.5 would probably need more frequent intervention than a lot of harnesses give. But I bet 4 could do a simple JSON API one-shot with the right harness. Just back then I had to manually be the harness.

[eddieroger]

I disagree it's a cop-out, but I agree it's hard to get good at writing prompts and takes a lot of effort. But so is programming. We're trading one skill set for another and getting a bigger return on it.

I started as a skeptic and have similarly drank the kool-aid. The reality is AI can read code faster than I can, including following code paths. It can build and keep more context than I can, and do it faster as well. And it can write code faster than I can type. So the effort to learn how to tell it what to do is worthwhile.

[apsurd]

yep fully agree. i'm taking issue with the flippant "not prompting right" as if they're holding it upside down vs it's actually a meaningful skill to have to invest in so it's fully believable that someone trained in normal code gen is much more proficient up front.

[yakbarber]

this seems disingenuous. even if your premise is true (which i don't think it is), it only really holds for the first few endpoints. most systems have many, and the models are very good at copying established patterns to the point that you wouldn't normally have to re-explain every detail for every endpoint. so you might be right for the first (you're not), but you're definitely wrong for the next 50.

[majormajor]

To be fair, I don't know many humans who would write endpoints 2-50 from scratch either in that situation.

Time-wise, it's easy-mode vs easy-mode at that point.

The human is more likely to make copypasta errors, though!

[awalGarg]

> > If I know the answer to all these questions, wiring it together takes me LESS time than passing it to Claude Code.

> That's just not true, and if it is in your case, then you're not great at writing prompts yet.

That's just not true, and if it is in your case, then you're not great at writing code yet.

[philipwhiuk]

> you’re not great at writing prompts yet

You know what we call adequately specifying the system such that the computer can run it as a viable system.

Coding. We call it coding.

[wiseowise]

> you’re not great at writing prompts

> provides not great prompt

[sdevonoes]

I have worked with people like you. Worst colleagues ever.