appsoftware

Like this apparently - in 6 steps. I have a PWA app planned, I was hoping I could write some easy instructions for each platform. There's likely to be some drop of with iOS though if the user has to navigate through all of this: https://www.reddit.com/r/webdev/comments/1nlwu0m/it_now_take...

It's anti-competitive for sure

That sounds likely

I created AS Notes (https://www.asnotes.io) (an extension for VS Code, Antigravity etc) partly because of this use case. It works like Obsidian, being markdown based, with wikilinks, mermaid rendering and task management. In VS Code, we have access to really good Agent harnesses and can navigate our notes and documents in a file system like manner. Further, using AGENTS.md, idea files etc we can instruct the agent how to interact, add to our notes etc. I've found working with my notes like this really useful, and provided I trim anything generated by an AI that's not going to be useful, provides an investment in the information I've gathered as the information is retained in markdown rather than getting lost in multiple chatbot UI s.

I don't understand it from the app developers point of view. Having to pay app store cuts over basic card processing fees. I understand the appeal of access to a market, like selling on eBay gets you eyeballs. But once you have a customer using their app, what does the app give you that a PWA doesn't unless you need access to specific sensors / file system access patterns etc?

I've released a free extension for VS Code that implements a kanban board in visual studio with a GitOps friendly markdown storage format that helps with a 'human in the loop' agent flow I've been working with to a high degree of success:

Agent Kanban has 4 main features:

GitOps & team friendly kanban board integration inside VS Code Structured plan / todo / implement via @kanban commands Leverages your existing agent harness rather than trying to bundle a built in one .md task format provides a permanent (editable) source of truth including considerations, decisions and actions, that is resistant to context rot

Hey, saw this while looking under new and wanted to try and help. I think the answer is to be places. Life needs randomness and interactions and that doesn't happen at home. Try to be in "3rd places" - the gym / work in a shared working space / pick up a couple of hobbies (I say a couple as just one is risky if say it's sports based an you injure yourself - something you can do outdoors, something you can do indoors). Trust that it will take time, but it will happen.

While building AS Notes (A wikilink-based knowledge management VS Code extension - https://github.com/appsoftwareltd/as-notes) - I ran into a subtle and genuinely interesting bug involving WebAssembly linear memory.

TLDR: sql.js loads SQLite into a WASM module with a single linear memory buffer. After indexing 18,000+ files that memory is large and fragmented. Reconstructing a Database() object on that same heap fails with "memory access out of bounds". The fix is a build-time esbuild plugin that injects a resetCache() function into the sql.js bundle, allowing the WASM module to be fully discarded and reloaded from scratch on rebuild.

The agent-flow repository serves as a template for a flow I've recently been using for agent-assisted coding - with impressive results.

Even with the best models, agent-assisted coding can be hit and miss. A good AGENTS.md that covers most of the mistakes you find agents making can go a long way, but this flow has been producing outsized results over the last couple of weeks.

It takes a little more discipline than hacking away in the chat window until you get what you want, but this process makes a "one shot" success more likely, and really pays off when things get complicated and the agent needs more of a steer.

If you already live in VS Code, maybe you like to manage your notes there too?

AS Notes brings Obsidian/Logseq-style knowledge management directly into VS Code - wikilinks, backlinks, page aliases, daily journal, and a task panel - without leaving your editor or touching a separate app.

The motivation was simple: most developers already take notes, but the friction of switching to another app means those notes slowly drift into neglect. AS Notes keeps everything in plain .md files + wikilinks, in a folder you control. There's no cloud sync, no accounts, no telemetry. The index is a local SQLite database powered by WASM (no native dependencies), so it works everywhere VS Code does. Because your notes are just markdown files, they get the same Git workflow as your code.

The feature I'm most pleased with is nested wikilink handling - `[[Project [[Alpha]] Notes]]` creates multiple navigable targets from a single link, which mirrors how Logseq-style linking naturally composes. There's also rename tracking: rename a file and AS Notes offers to update every reference across your workspace.

Install from the VS Code Marketplace or clone the demo notes repo to kick the tyres. Happy to answer questions about the architecture - particularly the WASM SQLite indexing approach.

GitHub: https://github.com/appsoftwareltd/as-notes

Marketplace: https://marketplace.visualstudio.com/items?itemName=appsoftw...

?? I'm using my own remote MCP server with openclaw now. I do understand the use case for CLI. In his Lex Friedman interview the creator highlights some of the advantages of CLI, such as being able to grep over responses. But there are situations where remote MCP works really well, such as where OAuth is used for authentication - you can hit an endpoint on the MCP server, get redirected to authenticate and authorise scopes etc and the auth server then responds to the MCP server.

I'd add using Discord as your chat channel to limit access to your contacts, and isolating access to personal data via mcp servers https://www.appsoftware.com/blog/openclaw-running-a-secure-c...

On my current project, we've settled on a system that reads environment variables from Hashicorp Vault, interpolates the variables into placeholders in config files, and then loads the processed config files in the app in memory. It works really well, is convenient to manage secrets for multiple environments and keeps the secrets off of the disk everywhere.

OLLAMA_FLASH_ATTENTION is essential for getting reasonable performance. Yes I did well with that laptop, it's been a trusty steed :) a refurb too.

Actually I disagree. I've killed projects because I've run out of time for them and didn't like them costing me £50 a month. If I'd been able to keep them going at £10 a month, I might have kept them going until I could get back to them. Sometimes startups fail just because the owners get distracted by life, and the project just needs more time.

A walk-through of how we built a terminal-based coding agent in ~400 lines of vanilla Node.js, running entirely on a local GPU with no cloud dependencies and no npm packages.

This is a walkthrough of my set up of local LLM capability on a Lenovo ThinkPad P1 Gen 4 (with a RTX A3000 6GB VRAM) graphics card, using Ollamafor CLI and VS Code Copilot chat access, and LM Studio for a GUI option.

My Lenovo ThinkPad P1 Gen 4 is coming up for 4 years old. It is a powerful workstation, and has a good, but by no means state of the art GPU in the RTX A3000. My expectation is that many developers will have a PC capable of running local LLMs as I have set up here.

See the GitHub repository for the full walk through:

https://github.com/gbro3n/local-ai/blob/main/docs/local-llm-...

Ref: https://www.appsoftware.com/blog/local-llm-setup-on-windows-...

This is the flow I've found myself working towards. Essentially maintaining more and more layered documentation for the LLM produces better and more consistent results. What is great here is the emphasis on the use of such documents in the planning phase. I'm feeling much more motivated to write solid documentation recently, because I know someone (the LLM) is actually going to read it! I've noticed my efforts and skill acquisition have moved sharply from app developer towards DevOps and architecture / management, but I think I'll always be grateful for the application engineering experience that I think the next wave of devs might miss out on.

I've also noted such a huge gulf between some developers describing 'prompting things into existence' and the approach described in this article. Both types seem to report success, though my experience is that the latter seems more realistic, and much more likely to produce robust code that's likely to be maintainable for long term or project critical goals.

Claude when used via Github Co-Pilot is much better for useage allowance. I used Opus 4.5 for a months worth of development and only just hit 90 pct of the pro $40 per month allowance.

I don't think a general public set of skills like this is going to work. I see value in vendors producing skills for their own products, and end users maintaining skills to influence agents according to their preferences, but too much in these skills files is opinion. Where does this end? Ordering of skills by specificity, such as org > user > workspace? And we know that skills aren't reliably picked up anyway. And then there's the additional attack surface area for prompt injection.

I use a common README_AI.md file, and use CLAUDE.md and AGENTS.md to direct the agent to that common file. From README_AI.md, I make specific references to skills. This works pretty well - it's become pretty rare that the agent behaves in a way contrary to my instructions. More info on my approach here: https://www.appsoftware.com/blog/a-centralised-approach-to-a... ... There was a post on here a couple of days ago referring to a paper that said that the AGENTS file alone worked better than agent skills, but a single agents file doesn't scale. For me, a combination where I use a brief reference to the skill in the main agents file seems like the best approach.

Location: Wiltshire, UK Remote: Yes (Remote or London) Willing to relocate: No Technologies: .NET 9/Core, C#, JavaScript, Cloud, Database, APIs + lots (see CV) Resume/CV: https://www.appsoftware.com/cv Email: gareth.brown@appsoftware.com

I am a Senior Software Engineer and Solutions Architect with over 18 years of experience building enterprise-grade systems for the public sector, FTSE 100 companies, and fintech startups.

I specialize in the .NET ecosystem and AWS cloud infrastructure, with a focus on building performant, secure, and maintainable systems. I’m equally comfortable leading a development team through complex technical migrations or being a hands-on individual contributor. I bring a pragmatic, "builder" mindset to software—focused on solving business problems with clean code and robust DevOps practices.

Outside of software, I’m an active and practical person who enjoys woodworking, art, literature and fitness including hiking and Brazilian Jiu Jitsu.

Looking for senior or lead roles where I can take ownership of technical strategy and delivery.

We're all ultimately just learning what we need to to get the job done. After 20 years programming, it is very clear that nobody knows everything. Everyone just knows their own little slice of the software world, and even then you have to 'use it or loose it'. If you're feeling imposter syndrome, keep a study side project going where you don't use any AI, something like NAND to Tetris that forces you to learn low level concepts, and then just stay productive using AI for the rest of your work.

Neither really. I don't want a tool to guide me or to generate content. My notes only have meaning to me if I know I wrote them, from my brain. I'm a fan of learning by proximity to the problems I have. Maybe a LLM based tool that highlighted conceptual connections to other notes, but in my mind these associations can be quite disparate and from sometimes completely different disciplines

Yes the block hierarchy is enough for re-entry. There is a natural 'pruning' process where I return to notes and realise I need to rework them to make surfacing the information I need easier. I often adjust titles and aliases (and often find I have two notes with similar names that need 'refactoring' to one - but Logseq makes this easy). If I don't find the note straight away I can usually remember adjacent terms to find it, and then when I do, I tag it with the first terms I searched on (as acceptance of the associations my brain had naturally made). I'll keep an eye on your project. What I do struggle with with Logseq is there isn't an easy means to just dump ideas to organise later, partly because the mobile app is so slow. It really needs two UIs that integrate with the same base format for two different modes of note collection. I disagree with others that taking or 'hoarding' notes is more work than its worth. The benefit of being able to dump info quickly and pick it up again and being able to find it easily is so valuable. Sure some notes get written and never see the light of day again, but then they never consume further time because I just don't work on them, but they are there if I need them. There's no way to know what info will definitely be useful in the future.

What would you take out of C# etc?

Obsidian is similar but without the block structure you have to be very specific about linking notes rather than using parent child relationships.

I like obsidian, but use Logseq day-to-day. I find it pretty easy to dump information without too much work due to the block / indenting structure. Retrieval isn't too bad, because you navigate to the wikilink you need, and everything is under it (I do sometimes swear I used a specific wiki link and then find I used something else, and have to dig for information).

Something that did work well recently, was creating a node script to gather all text under a given wiki link and copy to a doc with some formatting modifications, and then feed the document to an LLM for consolidation and a summary of everything I have recorded for a given subject.

I think this is where current senior engineers have an advantage, like I felt when I was a junior that the older guys had an advantage in understanding the low level stuff like assembly and hardware. But software keeps moving forward - my lack of time coding assembly by hand has never hindered my career. People will learn what they need to learn to be productive. When AI stops working in a given situation, people will learn the low level detail as they need to. When I was a junior I learned a couple of languages in depth, but everything since has been top down, learn-as-i-need to. I don't remember everything I've learned over 20 years software engineering, and the forgetting started way before my use of AI. It's true that conceptual understanding is necessary, but everyone's acting like all human coders are better than all AI's, and that is not the case. Poorly architected, spaghetti code existed way before LLM's.

I agree with the authors observations here. I think rather than it being purely language related, there's a link to the practice of 'rubber ducking', where when you start to explain your problem to someone else it forces you to step through the problem as you start to explain the context, the steps you've tried and where you're stuck. I think LLMs can be that other person for us sometimes, except that other person has a great broad range of expertise.

As AI coding assistants have become increasingly capable, I've developed a structured approach to integrating them into my development workflow. This post details how I've organised my codebase to work effectively with multiple AI agents - GitHub Copilot, Claude and others, while maintaining a single source of truth for instructions across multiple projects that share a similar tech stack and structure.