←back to thread

1013 points QuinnyPig | 5 comments | | HN request time: 0.936s | source
1. reactordev ◴[] No.44570837[source]
This looks really cool except for having to learn a new syntax (is gherkin that bad?) however, something has been bothering me with all of these Agent AI based workflows.

At what point do you actually do engineering? This was a great demo for a project manager. Lead your “team” through feature development. But without proper architecture, development really does become spaghetti.

There’s vibe coding - and then there’s this, where I feel like I’m a PM, not an engineer.

replies(2): >>44570866 #>>44574432 #
2. Insanity ◴[] No.44570866[source]
Yeah, I hear you. Vibe coding is good for a POC style thing as long as you can (somewhat) ignore architecture.

For any real-world application that is even slightly more complex than these demos it will start to fail.

At least that has been my experience

3. daxfohl ◴[] No.44574432[source]
It depends. A lot of projects / features really don't require a ton of engineering thought. Add a new table that has some foreign keys with existing tables, add a new page that lets you modify that table, add a new set of REST CRUD handlers that do some validation and store the data, add a new message queue that does whatever needs to happen when the data gets changed.

If AI can handle things like that, then let AI do it: it's not really engineering work anyway; it's copy-and-paste from a previous design, just change the handler logic and the names of things. If 90% of incoming features are like that, then that gives you a lot more time to work on the 10% that are more complex.

Eventually, you'll end up with spaghetti code no matter how well you plan out the architecture, whether human or AI is doing designs. But it'll move that direction even faster with AI, and eventually AI won't be able to understand it well enough to reliably design things anymore. That's where the real engineering will come in. As the system evolves, how do we re-architect things so that AI (and humans) can understand the patterns again and make future changes more reliably?

Right now, it seems like services go through major refactors/rewrites like that every five years or so. And those rewrites tend to be slow and often unsuccessful: even though the existing system is complex, engineers are used to it and it's easier to add one more bandaid than to wait for the full rewrite. Then such rewrites can get stuck in navel-gazing as there's no "perfect" way to do them, and it's lower effort just to go back to the system you already know.

As AI creates more churn though, the architecture will need to be rethought much more frequently. Additionally there will be more urgency to deliver the cleanup because AI will be completely blocked by the existing spaghetti, which brings all product dev to a halt, and you don't have time for navel-gazing because there's no fallback option.

So I think the engineering work post-AI is really going to be this kind of infrastructural planning and rearchitecting, such that AI can deliver features on top of it without friction. And in a way, as an engineer, that's what I want to be doing anyway. We've always had this ideal of continuous refactoring and continuous improvement, that always gets pushed to the backburner when compared to feature development. "Sure this refactor will help future velocity, but we need to make our quarterly goals!" But now, AI will compress those timelines so that maintaining clean architectures has a direct effect on the deliverables of the current quarter.

I personally think this is great. If, in the future, PMs can launch whole features without engineers writing a line of code, that's awesome. It's our job to maintain a system where such an ideal is possible. Which sounds like the job I wanted when I originally signed up to be an engineer.

replies(1): >>44575172 #
4. reactordev ◴[] No.44575172[source]
>And in a way, as an engineer, that's what I want to be doing anyway…

Yuk. That’s pure project management.

> If, in the future, PMs can launch whole features without engineers writing a line of code, that's awesome.

No it’s not! Because then, there is no incentive to engineer anything anymore. Just let the AI do it, Yey! Need new features? Let the AI do it! Need to fix your infrastructure, AI has your back! Has your product gotten so unwieldy that you have context rot and AI can’t do it anymore? Pivot, throw it away, rebuild with AI, who needs engineers.

replies(1): >>44576768 #
5. daxfohl ◴[] No.44576768{3}[source]
That's the thing though. I think we're pretty close to AI being able to add fairly vanilla features that fit into the existing architecture fairly autonomously. But I think we're a long way away from AI being able to do major refactors by itself, or even determine what needs refactoring and when. Maybe someday it will, and it can already be useful in implementing pieces of a refactor, but it's nowhere near close on being able to design a major platform shift at the moment. That's entirely a human domain.

So while we're in the middle of those two pivot points, I think most of our work will be on the architecture side. Continuously clean up the platform so the LLM agents can keep humming along on it.

Eventually we'll perhaps get to the point where AI can automate 100% of this as well, and I have no clue what will become of engineers then. But I don't see that happening in the next ten years, and even when it does happen, I'm sure the changes will create whole new industries, workflows, and sets of problems for human engineers to solve. (SciFi me expects a whole new field of extracting the most value out of AI without letting it run amock. As fast as it goes, and as intelligent as it will be, we won't be able to just let it take over. We'll need to design guardrails for it so that it does the things you want, and doesn't make decisions that you don't want. This, by definition, has to be a human driven process. So I think there'll be work for human engineers to do for a long long time.)