[wellpast]

I’m willing to be wrong but this industry-wide emphasis on AI creative/coding workflows seems way over-engineered.

Ime successful creative execution looks like micro-iterations where each output informs the next creative move.

I can build something incredibly fast from essentially caveman grunt instructions through an LLM harness, iterating as I go.

Optimizing for feeding a huge plan to an agent sounds to me like a net waste of time. And looking over the shoulder of industry peers trying to do this, I don’t see their outputs or throughput some remarkable improvement over what I can produce with minimal fanfare usage.

[Yokohiii]

LLMs are too flaky for high quality code. On tougher problems it's very common for an LLM to contradict itself and run in circles. It simply doesn't know what the right thing is, but on each turn it is super confident to do the right thing.

Maybe I've chosen hardmode to learn C with LLM assistance, plus my pet project turned out to be a bit less trivial then anticipated. But I know that I have to think three times about my choices how to deal with C problems and seeing how a LLM struggles to give reasonable answers is a a huge red flag and forces me to think about it a fourth time.

Doing all this with a fast autonomous workflow with just little user guidance is asking for trouble.

[coffeefirst]

It’s not just you. My last dumb pilot program making a Pocket clone in Python also got stuck in a loop regularly, which should be its strong suit...

I suspect that the “right” way to use LMs in coding, including accounting for focus, control, and costs is not a settled debate. We probably haven’t even seen the best ideas yet. But I’m really dislike the maximalist approach.

[doom2]

> Maybe I've chosen hardmode to learn C with LLM assistance

May you speak a little more about how you're approaching this? I was thinking of doing similar

[Yokohiii]

Well my process was/is quite messy. It started out as an experiment for a desktop app (which turned out to be a bit more complex than anticipated), mostly using copy and paste to try different approaches for a working prototype.

The progress is bottlenecked by how things are done with C. Most features went through an considerable LLM research phase to find the sweet spot how I want to solve it. In the feature phase I've coded more and more on my own and used the LLM as a reviewer on the critical parts.

I know a few things about C, but my knowledge is very passive, but there is already a path carved in my brain from influential C programmers you find on yt and blogs. That being said, LLMs will actively gatekeep and bullshit you about C and system architecture. You need to drill down hard, from different angles i.e. what is efficient and what is pragmatic or you question about how hardware actually works. They still may have blind spots and casually keeping things from you. Naively asking for code snippets will be tutorial style and often backfires, not unseen that they rant about their own code in another session. So you need to maintain a healthy balance of knowledge from trustworthy humans and the quickly available, but potentially inaccurate/incomplete LLM knowledge. Be critical, you are the captain.

LLMs are not bad at reviewing C code. They catch a lot of noob mistakes and are more helpful then compilers. But again they tend to produce tutorial solutions. They litter everything with malloc, which is something I am trying to avoid. I've not touched arenas yet, I want to fall flat on raw C to value them. They can teach you arenas, but I suggest to cross check with the real world, especially because you want ergonomics and correctness on that behalf.

Most C adjacent topics are easy to pick up on the go. Build systems, debugging, API vs ABI, static vs dynamic linking, macros, etc. A seasoned programmer can get a quick overview and ad hoc help, for things that are often buried in mediocre docs.

Also if you happen to come from more higher level languages or dynamic languages. Expect C to require easily 5x more code for literally anything.

If you prefer to learn the language more structured, work your way towards learning how to create data structures and algorithms in C. Make a clear distinction between static and dynamic allocation and learn along the road how C/hardware wants you to deal with memory.

[0x696C6961]

Yeah it's wild watching so many people decide waterfall is great all of a sudden.

[NamTaf]

Never mind stumbling into proper engineering principles like having documented, testable requirements specifications.

[dcrazy]

I”ve been pretty happy with this side effect of the agentic coding bubble.

[NamTaf]

As a non-tech engineer (mechanical, trains) it's fascinating seeing what is essentially the "not real engineers" SWE crew finally pay the piper because they've invoked what is in essence a non-compliant, cost-focused subcontractor and now need all of the same engineering rigours they never previously understood.

[bluGill]

Every large project in the coming back to waterfall. While the problems are certainly known and it was ultimately developed as a straw man, everything else ends up working worse. That said, you shouldn't be thinking pure waterfall as it's drawn up as a strawman, but rather a waterfall variation with feedback loops. But in the end, in very, very many cases, you have to know an end date in order to get things done because so many other things depend on you being done at the same time. If something is going to get done sooner you can't use it anyway without all the other pieces.

[NamTaf]

ITT we discover that project managers actually serve a purpose and not all of them are the stereotypical useless roles Dilbert riffed on.

[0x696C6961]

"waterfall variation with feedback loops" lol next we're going to have "agile where you plan everything up front"

[bluGill]

Pretty much what most agile ends up. Plans are worthless but planning is a valuable exercise. (Attributed to various generals)

[piazz]

100% agree. Took me ages of working with the agents to circle back around this, which was the best way to get work done before AI automation anyways.

[mewpmewp2]

For me it's usually that I start with a single agent, but then I won't have anything to do while it is churning and I have other ideas/features that keep building up that I want to do, so I need to scale, and while I'm scaling I need to start to have those workflows, so eventually I end up with many agents, most which are autonomous working on their own worktrees, but I will have a specific agent that I will talk to more iteratively.

So e.g. I may have 1 agent that I ask and iterate on with directly, and 9 agents that work separately on their own.

I will utilize this 1 agent on features I care most about and want to guide and iterate on in as much detail as possible.

[artursapek]

I agree. I have gotten an incredible amount of work done iterating with 5-30 minute long agent tasks. But it requires I stay engaged, and not go chill on the beach, which I guess is a lot of agentmaxxers’ goal.

[bunderbunder]

I suspect that letting agents spin away unattended for long stretches of time will become less and less popular as more and more companies blow their token budgets and start requiring some answers to difficult questions before agreeing to further loose the purse strings.

[fassssst]

The trick is to have 5 of those huge plans running in parallel.

[_zoltan_]

you do not need micro iterations. you can set macro goals and let the agent/LLM/model whatever you want to call it figure it out.

it works.