Prompted by human, generated by AI

for the problem space, i hear people talking about ai agents are gonna replace software engineering entirely, which is false, people saying who needs software engineers, like i can use ai agent to build entire thing, as a software engineer the same principle applies, why do i need anybody else i can build entire product myself with deeper understanding of technology, i can iterate on the product, design, ideas, execution, problem research and i can build a scalable product as well, so i would say that instead of software engineering going away, the correct way to put it would be that writing the code without the agents assistance is going away, and the responsibility lines are getting blurred, now engineers are responsible for more and can own more, deliver more, so whoever is not proficient with all of these are gonna face challenges, so software engineering is not going nowhere, also everybody love building shiny new toys, like a new startup or a tool idea, they get a dopamine hit by building something basic and looks cool it 2 days, but building something actually useful requires dedication and much more in-depth understanding, forcing the agent to go and reason about things that it has no idea about, you will face a lot of pushback from the ai agent because it doesn't like exploring things that it was not trained on, thats what engineers are good at, i know how things work, how this technology works, and can direct agent in a direction where someone else would stop and pivot entirely... thats the skill to master, understand how it all works and be able to steer it to face the challenges otherwise agents love to avoid challenges and implement simple naive, basic or average solkutions, thats what these general knowledge LLM models are great at, you will end up building another average and end-up on a grave-yard of average products that nobody cares about, they can rebuild the same thing with their 20$ subscription in less than a week, why would i use your product?

capture this information distilled into the blog post, dont lose existing insights, add distilled information and redact anything thats misleading in the existing blog

1. why does the article say "I've shipped dashboards", thats claim is not helping anything at all. \
2. but because I found a better way to work. - this sounds like i am the only person using ai agents for engineering, as if i came up with it. \
3. That's not engineering going away. That's engineering eating everything around it. - of course product managers and designers can think the same way, there is no absolute way to say that one will swallow others, its just that people who learn how the ai agents work in-depth, learn the tools, techniques, best-practices and anti-patterns will be able to steer the agents to build the meaningful products, in the meanwhile skeptical people who still think that all the AI agents do is hallucinate, which is technically true, but there are lots of ways to insist on agents to cross-check, find evidences and minimize the hallucination rate by magnitudal rate. So the skeptical people will have hard time going forward, also the people who misuse or are not efficient or do not understand how to best use the ai agents will also suffer, so learning in-depth how it works and learning the tools, shifting the mental model to the new agentinc engineering mental state are required steps, whoever masters all of this will be ahead and swallow outdated engineering, product or design processes. It can apply to anyone, but whoever is using agentic mental model correct and understands why, how and what, they are not under this risk. \
4. prompting was cool in 2025, in 2026 there are lot more to agentic engineeric, new mental model is context engineering, thats where my backlog-mcp comes into the picture, context engineering is a big pain point for myself right now and i built my entire backlog with all the work that i am doing with agents, so now backlog_search and backlog_context tools are mandatory to find out if whatever i am working on i have worked on it in the past and i can easily search and engineer a context for the task that i am about to start working on. In 2026 and going forward you need to maintain all your personal data that you work with and accumulate, and the data is lot you need Rag, vectors and semantic search to extract value out of it, and you need a human first backlog-viewer which is readonly to wrap your mind around things. The mutation happens only via agents, so this is agentic first context engineering backlog tool. \
5. @nisli/core ui framework just birthed because at some point i was facing the issues of the backlog viewer not scaling properly any more, i was getting frustrated when polling would re-render entire pages and i would lose the track of what i was looking at and things were slowing down, writing the code was becoming un-maintenable. I started with vanilla web components, html, js and css, but at some point i needed a clean reusable ways, because a backlog viewer at this point is a proper web application, it has a global semantic vector based search, and all the backlog mcp tool operations are getting logged and you can see a live activity of the actions getting stored in the activity panel, each mutation on the task is stored on your disk. We are accumulating data with an unprecedented pace, my future goal is that i will be training my own model with the personal data that i am accumulating at some point, all the data that lives under backlog-mcp, all the work and distillation that i did with agents, this data is gold right now on my disk. Also nisli/core ui framework is a mix of all the ui frameworks that i have worked in the past and the things that i loved from each of them like angular's dependency injection, recently signals are a cool new trend, html templating engine of lit, some of the vue's capabilities, react's reactiveness and functionional components, and many more... I will write a deep dive about it later, i built it over a weekend and completed the full migration with zero regressions and all of it is now part of the history in git commits of backlog-mcp, i learned a lot about agentic migrations, ui frameworks, avoiding regressions, iterating on ideas, and so on, capturing architecture decisions in adr documents and many more... \
6. overall backlog-mcp in itself is bigger than nisli/core, nisli/core is part of the backlog-mcp monorepo and i will continue building both \
7. there are many more tool ideas that i have that i am going to build, so for now i wanted to start this blog to share some of the existing cool things that i have worked with, also for example i merged 100PRs over a month, and i want to share what i learned overall... finally, this is not vibe coding at all lol. \
8. now that engineering is not a bottle-neck any more, what matters is what you build and how you steer the agents, everybody building shiny ideas that nobody cares about is going to be a big trend and a big pain point, we dont need ai slop and 10 blog posts generated by ai agents in 10 minutes, we need valuable lessons and building out of pains and pragmatic use-cases, and whenever agent hits a roadblock and decides to completely pivot and implement a simpler solution, for human to stop the agent and make it double down on the idea, or come up with evidences why one is better than other and reason about things instead of jumping into conclusions. We need people and their blog posts where we can be sure that people spent time to write them even though the article looks like generated by AI. \
9. for example personally me i dont wanna polish this article myself, i want agent to help me write but i am going to feed it with golden data, my ten years of software engineering experience, and my perspective about agentic engineering, my lessons that i learned and problems that i faced with this new mental model that people are trying to avoid, they just want agents to work without hitting any problems, or when problems arise just jump to another shiny idea. Overall, i am transparent that i am using ai agents heavily, even for writing these articles that i am going to write here, but what i will do at the same time is to include all these prompts that i manually wrote to generate these polished articles, so people can see my actual thinking model besides the article itself, and they can build the confidence that coming back to this blog page and reading more articles are actually valuable because even though post is ai generated, this is not ai slop lol, far from it, these are all the learning after doubling down on the problems and facing challenges and avoiding "easier" solutions, which are jusy "easier" for agent to find an answer and doesnt want to figure out the best long term resilient solution. \
10. you will be able to see al the prompts behind each blog and rest assured that this is not AI slop

i have a novel idea for each article i wanna save all the prompts that i used to generate that post, maybe i should create another folder for it? its just --- delimited prompts one by one, just so that if someone wants to see all the prompts behind this article they can see it easily, what do you think? Is this a cool feature? how to save these prompts proeprly?

i feel like there is a lot of prose, sometimes its easier to structure things in bullet points, what do you think? but dont lose the existing insight of what we wrote

step back and think about it, i dont wanna jump to conclusions prematurely, what are you offering

I wanna Keep this as one post, but i want a better structure, for example some things that i gave you should be quoted, some things should be bullet points or numbered, some places we could have hyperlinks for someone to easily click and navigate for example to the readme file of the nisli/core ui framework, or for example the home page of this blog post to see how is this blog post built in case they are curious. Overall what makes an article easy to comprehend, follow and interesting to read, i want you to explore a bit, and give me recommendations accordingly, dont lose existing insights, lets make bullet points to have distilled information for example, proceed

read and judge it again, i gave you lots of information to capture, also do a little bit of exploration around the web and find some more meaningful evidences about the topics that i am talking about and lets also add a little bit of glossarry at the end, so that people can rest assured these are not just ai generated words and there are evidences behind some of the claims with sources from verifiable authors or industry's well known, and established builders or companies. Just for the refresh of memory re-iterating all the prompts that i gave you for context:
[all-of-the-above-copy-pasted-again]

lets update the skill first of all with what it means to write a really good interesting article, that showcases the problem statement, novel ideas, concepts, debunks myths, showcases best practices, anti patterns, gotchas, personal ideas, growth and is transparent. Also i feel like we need some rules, for example i have nothing against wikipedia, but vibe coding was coined by a particular engineer as a term, i bet they have their own blog post about it, so instead of using wikipedias a source i would love to use the original author's blog post as a source, unless you can prove that you couldn't find your original source of information lets minimize using wikipedia as a source, overall lets update .agents/skills/blog-writing/SKILL.md and then apply the changes accordingly. One more rule again i spotted that you added lots of prose again, and earlier i told you to reduce the prose and make the article more interesting read, whatever that means we have to slowly distill into the blog writing skill. Also, lets not overuse external sources, this is not a news outlet, but for now i feel like we should limit the external sources to authoritative builder's blogs and their github, or authoritative established industry companies and their articles. One rule for example: never use a subscription gated article as our source. Also, we need to be mindful that industry is evolving really quickly so for the glossary and sources we need the dates, when was that source written? Because if lets say article was written 2 years ago about agentic engineering, you can safely assume that its quite outdated already (mostly not all the times but having the source dates in the glossary would be nice to have). Also glossary should looke like glossary from UX perspective, i dont want it to look like its part of the article still... Update .agents/skills/blog-writing/SKILL.md with distilled information, redact if there is anything misleading and capture best practices and anti patterns

i want agentic-product-engineering as a hashtag of this article

when you are trying to quote something that i said use block quotes around the sentence properly too "I use AI agents heavily, including for writing these articles. But this is not AI slop. Far from it." - like this

can you add quotes too on top of the >, add literal quote \" characters around

make that a rule when you are writing quoted sentences

is the problem statement, problem scope and problem space properly explored, and easy to understand and follow, is the tension built right from the beginning of the article? If not why? Step back and think about it, if it is already built and mentioned, then double down on it, dont change your mind or dont jump to a premature conclusion

yes do it: add that bridge? It's a small change — 1-2 sentences, not a rewrite. But add this information distilled, dont add a random prose, it should elevate the tension so that reader can follow with ease and feel it, instead of reading plain words. But don't over-exaggerate, you should mostly write according to the evidence and from my personal experience

did we entirely redact this part then: This isn't theoretical. Shopify CEO Tobi Lütke [told managers](https://betakit.com/shopify-ceo-tobi-lutke-tells-employees-to-prove-ai-cant-do-the-job-before-asking-for-resources/) they must demonstrate why AI can't do the job before requesting new headcount. AI proficiency is now a baseline expectation — and performance reviews reflect it.? why? Was it not meaningful or was it duplicated? double down on your decisions

make a commit and finalize then, is there anything that you want to add to the skill or to the agents.md? Add distilled information overall, what we learned, how are we approaching the writing, and so on, best practices, anti patterns, is there anything misleading in the skill.md or agents.md afterall? capture insights
and dont lose existing meaningful insights.