logoalt Hacker News

righthandyesterday at 5:09 PM6 repliesview on HN

But is it really any faster than using an already existing code generator/scaffolding tool? How do you know your project isn’t just a regurgitation of another repository? Would it be just as fast to clone some existing project and hack on it?

These are the questions everyone seems to be ignoring and saying “only LLMs can make projects quickly” but ignoring everything those LLMs are built on (your llmis probably calling a code gen tool).

For the at work side, I personally haven’t experienced any disadvantages or missed any project deadlines because I didn’t use an LLM, so what does velocity get me? Thumb twiddling time?


Replies

dataviz1000yesterday at 5:25 PM

It reminds me of Drupal circa 2009.

I was thinking the other day how much better Drupal is. Want a online store? A few commands and bam, online store. Want a newspaper? A few commands and bam, newspaper with publishing workflows, user management, and caching.

Using coding agents isn't much different. There are several things the models are trained to do very well and a few commands will get something. If the developer wants to move the project beyond that, it requires domain knowledge and a lot of hacking.

I wonder if the coding agents will move towards the Drupal model where they create interchangeable components with common interfaces. Like Drupal the coding agents never provide anything truly inovative that hasn't been done before.

show 3 replies
anonzzziesyesterday at 5:31 PM

> But is it really any faster than using an already existing code generator/scaffolding tool?

Yes, very much so. Our team was fast with those tools and created many of our own before this LLM AI (we used other AIs though to go faster), however it still took weeks to months from idea to launch; the same complexity now takes days, including everything. We already had rigorous processes and those really help now moving at speed. No way anyone can beat this except better AI.

show 1 reply
hparadizyesterday at 5:49 PM

Yea cause it's done while you're still reading the docs for your code generator. lol

show 2 replies
gchamonliveyesterday at 6:01 PM

Your tone makes me think you already decided that agents aren't worth your time, but I'll give it a try anyways.

I work as a DevOps engineer and have been using agents exclusively to code since the beginning of the year. Agents are really nice to quickly craft utilities to speed up planning. For instance I had it create a small cli for me that'll pull my cards from azure DevOps, load them as json, markdown and csv, and push updates once I'm done. Then I'll load into context transcripts of meetings and other written requirements, cross with current state of repos, to have meaningfully conrextualized work items without me having to implement these myself. I'll just have a long chat with the agent exploring these cards and defining the necessary refinements for description and acceptance criteria than I jusr push them all at once. Anything you can think of you just ask for the agent, so for me I don't trust code, so I'll have all my clis be no-op by default, so they will first print all they'll do and if I think the changes make sense I approve them and let the script commit to the canonical board.

Working with cloud consoles like Aws in general is a huge hassle, so crafting quick inventory utilities and tools for correlating data is a breeze.

Now the work itself is mainly ci pipelines, terraform files and automation. For these I'll base the agents on the specified work items and enrich them with my own understanding of the problem. I then launch the agents and read the agent output attentively. This is very important. You can't just prompt and leave, you need to be present all the time so you can steer the agent into solving the right problems. At the very least you need to review all the changes after an implementation session is done when you came back from making coffee. Many times it tries to create meaningless abstractions or very complicated solutions that I know can be done better. Or I have a different idea of how to organize the project so I do many follow-up sessions to refactor code.

In my personal projects I do a lot of small utilities. I spent some weeks designing and polishing a replacement for zurg and debridmediamanager the way I like it to be, simple and to the point, also tightly integrating them with jellyfin https://gitlab.com/gabriel.chamon/buzz

I have my own micro desktop environment on top of hyprland called Archie which recently I've been redesigning and improving a lot with agents https://gitlab.com/gabriel.chamon/archie

I have my own agile based methodology for creating and managing work items with tight integration with gitlab https://gitlab.com/gabriel.chamon/orisun

I have been improving my fork if gamma-launcher so that installing and managing the game on bazzite is simpler and more automated than relying on workarounds for workflows intended for windows https://gitlab.com/gabriel.chamon/gamma-launcher

Now for how I approach developing with agents. I think it's really important to get your constraints sorted out as soon as possible, so have your agent create a CI pipeline for code quality testing, like with ruff, pyright and pytest, to control style, code consistency and cyclomatic complexity. Put in the AGENTS.md explicit instructions that the agent must run these tools at the end of every coding session. If adopting a new project, use the agent to explore the code and see which refactoring points are worth tackling. Agents really thrive on good codebases, so this first code quality improvement pass is a must.

To sum it up, with agents you give up writing code manually for reading lots of code, exploring the domain with the help of the agent and architecting the solution at a strategic level. You trust the agent but you also verify. And lots and lots of manual testing. My personal take is that I'm infinitely productive now, only constrained by how much code and agent terminal output I can read, and also by the rate limits of the model providers and mental fatigue.

show 2 replies
utopiahtoday at 6:24 AM

Yes... and in fact I'm a professional prototypist (as in I get paid to do that) and this is 100% the process.

You do not, never EVER, start from a blank slate.

Step 0 is to actually challenge the value. Before you even start you spend a LOT of time with the person with a need to narrow down what they actually need. Not what they think they want but what's genuinely problematic for that. Again, NOT how to solve it but what's a thorn that's painful for them, not for what you imagine it might be. This honestly often get uncomfortable quickly because you have to ask "Ok but have you tried this? What about this quirky thing?" because it challenges their own attempts. If you don't spend a significant amount of time in that space you WILL implement faster, that's obvious, but you are very likely to efficient "solve" the wrong problem. You will solve what you can solve easily. Think about it like looking for keys where there is light, not where you lost them.

So... that's before one has even started to code, it's mostly uncomfortable discussions. Only once there is some confidence from both parties that the problem is identified can implementing might make sense. Then you don't! You do NOT touch a line of code. Instead you take whatever you can, post-it notes, Lego bricks, existing software, you tape all that together and you ask "Would THAT (very ugly barely working monster) kind of solve it for you?". So you do not build anything new, you ONLY stick together the BIGGEST existing parts.

Only then you might eventually build something but STILL you don't start from a blank slate. You are going to find the highest level of abstraction you can find. They want something related to the Web? You don't freaking build a Web browser, or a even PWA, you paste a code snippet in the console.

You always look for the way with the MINIMUM amount of new code. It's never about implementing faster. It's about NOT implementing faster.

Now the fun part (arguably) actually begins when you have done all that but it's still not enough. You use a CMS or a browser or whatever large exiting verified code base and the need is not solved. Then you rely on the built-in extension system of that code! Guess what, there might even be an existing plugin that does what you thought was novel.

Finally, finally you did find no extension for that existing quality open-source large code based so you HAVE to build it. Well, not so fast, is there another piece of code from another software that does it? Does it have an API? Can you connect to that API to get that functionality in that extension?

Then you have done it, you brought together 2 large pieces of software but you only coded the connector between the two.

Your prototype is, in practice, 10 lines of code.

TL;DR: yes, good prototypists code very little and yet still end up with genuinely novel work.

bluefirebrandyesterday at 6:03 PM

I think you're right

Imagine if instead of f AI generated code, we all just started copying and pasting code from open source repos.

Imagine my velocity! I cloned the Linux kernel in seconds!

Instead we're basically doing exactly that, except through an AI remixer.

It leaves a very sour taste in my mouth