As long as interfaces are well defined, comprehensive tests are written, memory is safely handled and time complexity is analyzable, who cares what the rest of the code looks like.

I understand programming for the sake of programming, chasing purity and really digging into the creative aspects of coding. But I get that same kick out of writing perfect interfaces, knowing that the messier the code underneath is, the more my beautiful interface gets to shine. But transformers are offering us a way to build faster, to create more, and to take on bigger complexity while learning deeply about new domains as we go. I think the more we lean into that, we might enter a software golden age where the potential for creativity and impact can enter a whole new level.

> As long as interfaces are well defined, comprehensive tests are written, memory is safely handled and time complexity is analyzable, who cares what the rest of the code looks like.

Software engineers and anyone who'd get hired to fix the mess that the LLM created. Also, ironically, other LLMs would probably work better on...not messy code.

> But transformers are offering us a way to build faster, to create more, and to take on bigger complexity

Wow. You sound as if building faster or creating more is synonymous with quality or utility. Or as if LLMs allow us to take on a bigger level of complexity (this is where they notoriously crumble).

> we might enter a software golden age where the potential for creativity

I haven't heard of a single (good) software engineer whose creativity was stifled by their inability to code something. Is an LLM generating a whole book in Hemingway style considered creative, or a poem? Or a program/app?

> As long as interfaces are well defined, comprehensive tests are written, memory is safely handled and time complexity is analyzable, who cares what the rest of the code looks like

The thing is, code that does all of the things you listed here is good looking code almost by definition

If AI was anywhere near capable of producing this quality then it would be so thrilling, wouldn't it?

But it's not. The consensus seems to be pretty universal that AI code is Junior to Intermediate quality at best, the majority of the time

That generally isn't code that satisfies the list of quality criteria you mentioned

Do you give the agent a style guide?

Do you perform (or have another agent perform) code reviews on the agent's code?

Do you discuss architecture and approach with the agent beforehand and compile that discussion into a design and development plan?

If you don't do these things, then you're just setting yourself up for failure.

That’s just the hallmark of good software engineering or do you think everyone else was cowboy coding things with Vim before?

Seemingly so going by the sibling comment to yours.

Ah yes the tried and true "you're holding it wrong"

By the time I did all the stuff you're suggesting, I could just build the damn thing myself

Would you skip these guardrails when working with a "Junior to Intermediate" developer?

No, but the goal of mentoring a Junior or Intermediate developer is that they eventually learn this stuff on their own. The value of helping another human grow is worth the tradeoff

AI is a tool, not a human. I'm not about to invest in it the way I would a Junior developer. If the tool doesn't do the job, it's not a good tool. If a tool requires the same level of investment that a human does it's also not a good tool

These factors are now getting baked into the tools. Primarily via prompt engineering, and what might be called "agentic design," which is how much complexity you put into a single pass vs some hierarchical layering of agents and tools with distinct jobs.

I've been deobfuscating claude code to watch their prompts evolve as I use it and you an see the difference around how and when it chooses to re-analyze a codebase or how it will explicitly breakup work into steps. A lot of the implicit knowledge of software engineering is being added, _outside_ of the LLM training.

But you are holding it wrong, and experience is the difference in being able to recognize when oft-repeated advice should actually be seriously considered, vs dismissing entire swaths of engineers who are holding it right.

Do you know how tiring it gets to constantly engage with people who complain about agentic workflows without actually having the experience or knowledge to properly evaluate them? These people already have intentionally closed their minds on the subject, but still love to debate it loudly and frequently even though they have little intention of actually considering others' arguments or advice. What could be an educational moment turns into ideological warfare reminiscent of the text editor or operating system wars.

It's beginning to get infuriating, because of the unbridled arrogance typically encountered by naysayers.

Yeh, exactly. Code doesn’t matter. Correct and stable electrical states matter.

Energy based models and machines that boot strap from models, organize their state to a prompt are on their way. The analog hole for coders is closing.

Most software out there is the layers of made up tools and such to manage and deploy software. We’ll save a lot of cycles pruning it all for generic patterns.

5-10 more years it’s all hardware again. Then no longer need to program a computer like it’s 1970.