[hombre_fatal]

I think the upper limit is your ability to decide what to build among infinite possibilities. How should it work, what should it be like to use it, what makes the most sense, etc.

The code part is trivial and a waste of time in some ways compared to time spent making decisions about what to build. And sometimes even a procrastination to avoid thinking about what to build, like how people who polish their game engine (easy) to avoid putting in the work to plan a fun game (hard).

The more clarity you have about what you’re building, then the larger blocks of work you can delegate / outsource.

So I think one overwhelming part of LLMs is that you don’t get the downtime of working on implementation since that’s now trivial; you are stuck doing the hard part of steering and planning. But that’s also a good thing.

[SchemaLoad]

I've found writing the code massively helps your understanding of the problem and what you actually need or want. Most times I go into a task with a certain idea of how it should work, and then reevaluate having started. While an LLM will just do what you ask without questing, leaving you with none of the learnings you would have gained having done it. The LLM certainly didn't learn or remember anything from it.

[jeremyjh]

In some cases, yes. But I’ve been doing this awhile now and there is a lot of code that has to be written that I will not learn anything from. And now, I have a choice to not write it.

[orbisvicis]

Ehh, I find that the most tedious code is also the most sensitive to errors, stuff that blurs the divide between code and data.

[claytongulick]

I actually like writing the tedious code by hand.

The whole time I'm doing it, I'm trying to think of better ways. I'm thinking of libraries, utilities or even frameworks I could create to reduce the tedium.

This is actually one of the things I dislike the most about LLM coding: they have no problem with tedium and will happily generate tens of thousands of lines where a much better approach could exist.

I think it's an innovation killer. Would any of the ORMs or frameworks we have today exist if we'd had LLMs this whole time?

I doubt it.

[jeremyjh]

I doubt if we're talking about the same sort of things at all. I'm talking about stuff like generic web crud. Too custom to be generated deterministically but recent models crush it and make fewer errors than I do. But that is not even all they can do. But yes, once you get into a large complicated code base its not always worth it, but even there one benefit is it to develop more test cases - and more complicated ones - than I would realistically bother with.

[stavros]

It depends on how you use them. In my workflow, I work with the LLM to get the desired result, and I'm familiar with the system architecture without writing any of the code.

I've written it up here, including the transcript of an actual real session:

https://www.stavros.io/posts/how-i-write-software-with-llms/

[jeremyjh]

Thanks for writing this up.

I just woke up recently myself and found out these tools were actually becoming really, really good. I use a similar prompt system, but not as much focus on review - I've found the review bots to be really good already but it is more efficient to work locally.

One question I have since you mention using lots of different models - is do you ever have to tweak prompts for a specific model, or are these things pretty universal?

[stavros]

I don't tweak prompts, no. I find that there's not much need to, the models understand my instructions well enough. I think we're way past the prompt engineering days, all models are very good at following instructions nowadays.

[galaxyLogic]

Right when you're coding with LLM it's not you asking the LLM questions, it's LLM asking you questions, about what to build, how should it work exactly, should it do this or that under what conditions. Because the LLM does the coding, it's you have to do more thinking. :-)

And when you make the decisions it is you who is responsible for them. Whereas if you just do the coding the decisions about the code are left largely to you nobody much sees them, only how they affect the outcome. Whereas now the LLM is in that role, responsible only for what the code does not how it does it.

[eucyclos]

Hehe, speak for yourself- as a 1x coder on a good day, having a nonjudgmental partner who can explain stuff to me is one of the best parts of writing with an llm :)

[galaxyLogic]

I like that aspect of it too. LLM never seems to get offended even when I tell it its wrong. Just trying to understand why some people say it can feel exhausting. Instead of focusing on narrowly defined coding tasks, the work has changed and you are responsible for a much larger area of work, and expectations are similarly higher. You're supposed to produce 10x code now.

[eucyclos]

Not sure if it's what you're talking about but I had a coworker trying to break into eSports and he talked a lot about the micro vs macro skills a game requires. Sounds like we all have an aimbot for programming so the competition has shifted hard towards the macro. That could definitely be tiring.

[lelanthran]

> Because the LLM does the coding, it's you have to do more thinking. :-)

I keep seeing this sentiment, but it sure sounds wrong to me.

Coding requires thinking (in humans, at any rate). When you're doing coding, you're doing both coding-thinking and the design thinking.

Now you're only doing one half of it.

[deevelton]

This hits home for me. Lawyer, not developer here. Implementation was never a hard part for me, it was an impossible part. Now that the time/cost needed to experiment with prototypes has dropped to near zero I've been been spending a lot of time doing exactly what you describe (steering, brainstorming). I find it fun but I do it mainly as a bunch of personal side projects. Can understand how it might feel different for users when the stakes are much higher (like when it's part of the day-to-day in a real job).

[clickety_clack]

I’d love to see what you’ve built. Can you share?

[jplusequalt]

>how people who polish their game engine (easy)

This is such a weird statement. Game engines are among the most complicated pieces of software in existence. Furthermore, a game that doesn't run smoothly increases the chances that your player base doesn't stick around to see what you've built.

[grey-area]

Maintenance is the hard part, not writing new code or steering and planning.

[ipaddr]

You can outsource that to another llm