Hacker News Reader

Comment by itmitica | Hacker News Reader

Interesting project.

Interesting readings in the project, such as https://github.com/desplega-ai/advanced-context-engineering-....

I'm not sure why, but I keep trying to reject this, subconsciously. Like, there is something I can't define that is not right.

I think it revolves around two things

No actual future benefits from abandoning the problem solving to a temporary swarm construct that will have a solution ready but potentially having learned nothing from the experience, that could be used in the future.

Shifting the engineering from stable sourcecode and frameworks to ephemeral prompting one-shot-and-done solutions.

Has programming become too meta?

View on HN

I think the concept can and will work and become the norm, but there is a lot of refinement and first-principles rethinking still needed. The ideas we see today are still unripe and need work. But we are on to something here.

100%. I believe the best thing to do now is find ways to push the limits of what works and what not, which will help find the following limits, and keep going

Yes, I spent too much time meta programming while working on desplega.ai (my startup). And I believe currently the best approach is a mix.

Have the swarm work on stuff you could delegate to an intern and basically have the feedback loop with it in slack and github.

On the other hard locally focus on the hard things you want to control.

I too was convinced at one point the spec is the program.

That it doesn't matter the implementation stack.

But, after wasting too much time in the meta, with nothing really to show for, I returned to controlling the programming process in fine detail. Progressive agentic/vibe coding, if I was to give it a name.

But it could be that I'm slow to understand how it can be done in a better way.

I believe that it’s a matter of evolution. You start small and find what works fir you and the project. Then iterate and see how to remove yourself from it more.

I actually wrote about this concept here if that’s something the might interest you: https://www.tarasyarema.com/blog/2026-02-18-introducing-sema...

I like your content very much, let me point this out first.

I'm not sure all aspects are covered in the approach.

For instance, controlling the agents takes a big chunk of the interest. The agentic system architecture is also big in view.

But, the way I see, more important staff is: project structure, coding best practices, testing strategies. All still deterministic. All still very tough to get agentic to do it right.

I think agentic should just be means to an end: project quality and project ease of management. If not, it's just an indulgence that costs money.

First of all, thanks!

And agree on the open questions. Our goal is to keep experimenting and actually figure out how we agentic coding falls short in different scenarios and how that could be solved.

For instance, on our own projects, in some cases it requires different approaches. E.g. in our core product we power-use stuff like pm2, AGENTS.md special instructions, testing strategies dogfooding our own qa-use and special claude code commands that we found work best. In other repos, we have slightly different approaches.

Still we are far from autopiloting a lot of the stuff we build. But at the same time we are getting to a point where changes are done much faster, and the agents have more of a complete toolset for their validation, which makes it easier to supervise too.

I appreciate your work.

But, again, from a productivity point of view, and from a correctness of approach point of view, I have learned this:

1. Avoid overengineering against/at all costs.

2. Doing the project is doing the project, anything else is ... not doing the project :) https://www.softwaredesign.ing/blog/doing-the-thing-is-doing...

Hehehe very meta.

It sounds like sharpening the knife before cooking is not cooking... But definitely will help make better food...

I think this progressive/gentic vide coding would work better if the tools were better and storing the history in a good immutable way, kind of like an email program. I have very valuable sessions where I give the agent a good ephemeral spec, something not sensible to persist in the codebase, but important enough to track it somewhere. Throwing away history is a big no no. Bad GUIs/TUIs discourage from relying on the history. When I close a session, I feel I'm throwing away the history. I keep many terminals open, but eventually have to close them. Tools will get way, way better to facilitate this "general on the frontlines commanding the agents" style of work.

Reply on news.ycombinator.com