I think that's an incredibly reductionist and sarcastic take. I'm also in Product, but was an engineer for over a decade prior. I find that having strong structured functional specifications and a good holistic understanding of the solution you're trying to build goes a long way with AI tooling. Just like any software project, eliminating false starts and getting a clear set of requirements up front can minimize engineering time required to complete something, as long as things don't change in the middle. When your cycle time is an afternoon instead of two quarters, that type of up front investment pays off much better.
I still think AI tooling is lacking, but you can get significantly better results by structuring your plans appropriately.
I understand that you are serious. I am also serious here.
Have you built anything purely with LLM which is novel and is used by people who expect that their data is managed securely, and the application is well maintained so they can trust it?
I have been writing specifications, rfcs, adrs, conducting architecture reviews, code reviews and what not for quite a bit of time now. Also I’ve driven cross organisational product initiatives etc. I’m experimenting with openspec with my team now on a brownfield project and have some good results.
Having said all that I seriously doubt that if you treat the english language spec and your pm oversight as the sole QA pillars of a stochastic model transformer you are making a mistake.
The issue is that validation needs presence and it is the limiting factor - common knowledge, but is part of the “physics”. Also maintenance gets really tricky if the codebase has warts in it - which it will have. I get much more easy to understand architecture out of an LLM driven code generation process if I follow it and course correct / update the spec process based on learnings.
Example: yesterday I’ve introduced a batch job and realized during the implementation phase that some refactoring is needed so the error boundary can be reused in the batch application from the main backend. This was unplanned and definitely not a functional requirement - could be documented as non-functional. There was a gap between the agent’s knowledge and mine even though the error handling pattern is well documented in the repository. Of course this can be documented better next time if we update the process of openspec writing but having these gaps is inevitable unless formal and half-formal definitions are introduced - but still there needs to be someone with “fresh eyes” in the loop.
I think it's just sarcasm coming from the stereotypical HN attitude that Product Managers only get in the way of the real work of engineering. Ignore it; they're basically proving your point.
I'd suggest you to work on your general mood - drugs can help, but nature is also wonderful.
I think I have a relatively good life, but I still have hard times. I had circa 6 months long depression streak after my child was born (I'm male).
For me the best mood fixer is a walk still. Super small commitment, great with a dog too. For a weekend the best is a longer hike. I practice yoga and train my body - great mood boosters. I've trained my body to be able to sit comfortably on the ground so I can work from anywhere - sunshine in park hellooo.
So you had generated 2000 lines in 30 minutes and ran out of tokens? What was your prompt?
I’d use a fast model to create a minimal scaffold like gemini fast.
I’d create strict specs using a separate codex or claude subscription to have a generous remaining coding window and would start implementation + some high level tests feature by feature. Running out in 60 minutes is harder if you validate work. Running out in two hours for me is also hard as I keep breaks. With two subs you should be fine for a solid workday of well designed and reviewed system. If you use coderabbit or a separate review tool and feed back the reviews it is again something which doesn’t burn tokens so fast unless fully autonomous.
I agree - we should use the tools. But we should be mindful about how humans actually learn.
Some improvement ideas:
A prototype can help in the “Better communicate the idea/feature” part but it is even better if you let engineers do this as learning by doing is better than just being shown the result.
Vibe coding doesn’t help in “Understand the systems” - on the contrary, this is already a well known fact that vibecoding has negative effect in understanding the underlying system. It should be hardboiled documentation reading, trial and error which helps, otherwise you get only the illusion of competence.
My summary: openclaw is a 5/5 security risk, if you have a perfectly audited nanoclaw or whatever it is 4/5 still. If it runs with human-in-the-loop it is much better, but the value is quickly diminishing. I think llms are not bad at helping to spec down human language and possibly doing great also in creating guardrails via tests, but i’d prefer something stable over llms running in “creative mode” or “claw” mode.
Taiwan is a different story. There are quite detailed war simulations built for defending the country. I guess you might mean that russia is one of the “3 big world” powers and their move is the special operations to capture kiev. I stop here
Yes, I meant China, Russia and the US with the "3 big world" powers and yes, I was referring to the war in Ukraine. I am aware that the situation in Taiwan, Ukraine and Venezuela cannot be compared one-to-one. My categorization was not intended to suggest that these 'moves' are the same, nor to make any evaluation regarding good or bad. From the respective perspectives of the 3 world powers, they have been motivated by different interests. The important point is that each of the three will use the moves of the others to justify their own, whether this is correct or not.
reply