Just on the coding side, tools like Claude Code/Codex can be incredibly powerful, but a lot of things need to be in place for it to work well:

* A "best practices" repository: clean code architecture and separation of concerns, well tested, very well-documented

* You need to know the code base very well to efficiently judge if what the AI wrote is sensible

* You need to take the time to write a thorough task description, like you would for a junior dev, with hints for what code files to look at , the goals, implementation hints, different parts of the code to analyse first, etc

* You need to clean up code and correct bad results manually to keep the code maintaineable

This amounts to a very different workflow that is a lot less fun and engaging for most developers. (write tasks, review, correct mistakes)

In domains like CRUD apps / frontend, where the complexity of changes is usually low, and there are great patterns to learn from for the LLM, they can provide a massive productivity boost if used right.

But this results in a style of work that is a lot less engaging for most developers.

▲

easyThrowaway 13 hours ago | parent | next [-]

But it also feels way more like a modernized version of those "UML To Code" Generators from the early 2000 rather than the "magic AI" that MS and Google are trying to market.

▲

the_duke 11 hours ago | parent [-]

I'd disagree with that, if given enough compute LLMs can have impressive capabilities in finding bugs and implementing new logic, if guided right.

It's hit or miss at the moment, but it's definitely way more than "UML code generators".

▲

yvdriess 10 hours ago | parent [-]

It's not the same, but boy it sure does rhyme.

Typical prose in late 90's early 00s: Designing the right UML meta-schema and UML diagram will generate a bug-free source code of the program, enabling even non-programmers to create applications and business logic. Programs can check the UML diagram beforehand for logic errors, prove security and more.

	▲	thunky 8 hours ago \| parent [-]
		I never used those so correct me if I'm wrong but those UML tools were more of a one way street: diagram -> code. You couldn't point it at an existing codebase and get anything of value from it, or get it to review pull requests, or generate docs. And even for what it was meant for, it didn't help you with the design and architecture. You still had to be the architect and tell the tool what to do vs the opposite with LLMs, where you tell it what you want but not how to shape it (in theory).

▲

stillpointlab 3 hours ago | parent | prev | next [-]

Your list almost exactly matches my experience and deserves to be a blog post explaining how to use LLM coding agents effectively.

However, I think the applicability is beyond frontend (and to be fair you said "like CRUD apps / frontend"). There are a lot of domains where patterns are clearly established and easily reproduceable. For example, I had a basic XML doc type and with a couple of simple prompts in Claude Code I was able to: add namespaces, add an XSD, add an XSL to style into HTML, add full unit tests. That isn't rocket science, but it isn't code I really want to write. In 5 minutes I leveled up my XML doc significantly with a few hundred lines of XSD/XSL/tests.

This example is a case where I happily pass the task to an LLM. It is a bit like eating my vegetables. I find almost no joy in writing schema docs or tests, even when I recognize the value in having them. The XSL to HTML is a nice added bonus that cost me nothing.

▲

benterix 12 hours ago | parent | prev [-]

> This amounts to a very different workflow that is a lot less fun and engaging for most developers.

That's my experience exactly. Instead of actually building stuff, I write tickets, review code, manage and micromanage - basically I do all the non-fun stuff whereas the fun stuff is being done by someone (well, something) else.