As a hobby coder I generally use jupyter notebook. I haven't used VS in almost a decade. Jumping into C# for a Unity project, holy hell intellisense has become an adhd nightmare. How can I tone it down so I can still get useful info but not have to do keyboard gymnastics to type simple lines of code? For example whenever I type g, it autocompletes to global... every little thing I type I get pop ups asking if I mean this or that interrupting my flow, I just want to code! EDIT: SOLVED!

As a new lead I got into this situation that might be familiar to a lot of people.

The code base is full of tech debt (what else) that no one ever cleaned up because shipping features was more important. So important that the code base became a collection of poorly designed things over the years that barely anyone knows about or touches.

Things that should have been cleaned up years ago are now starting to become apparent. They drag us down.

With a new PM, the team somewhat is more organized now but reducing tech debt is not on anyone's radar. In fact, PRs are sometimes piling up debt again that could be avoided in the first place if people would stop rushing.

I want to get this under control. How do you manage this with a team?

I thought about suggesting to actively plan the reduction of tech debt and reserve 30% of every iteration for unplanned stuff (bugs, urgent requests) and tech debt reduction.

This is not very popular with business and PMs but what can you do? What is your way that got acceptance from both devs and the business?

Edit: maybe I want to add: with gracefully I mean actively planned and with wits. Fixing a bug because you passively run over it by accident is not what mean by that ;)

We'll finish a feature, everyone's happy with it, and then it sits there. Review takes forever, then testing takes forever, then deployment takes forever. I feel like I spend more time shepherding code through the pipeline than writing it. Tried streamlining things a few times but the handoffs between teams kill any momentum. Any solutions for this?

1. Pull up documented conversation - receipts ready
2. Search frantically for proof (sometimes find it)
3. Apologize even when I'm pretty sure we did discuss it
4. Avoid conflict - just do what they want now

How do you write technical documentation such as requirements, goals, software architecture, and general project documentation?

Back in the pre-AI era, it was common to write long, multi-page documents that explained everything in detail. That approach had its pros and cons. The documentation was usually well organized and comprehensive, but it was also often boring to read and sometimes overwhelming.

What does it look like now, in the era of AI coding assistants? My impression is that large, comprehensive documents are becoming much less common and mostly remain in legacy projects or a few specific use cases.

It feels like the entire world has shifted to Markdown, so I assume technical writing is evolving in the same direction. It makes sense to break up those oversized documents into smaller, focused files so that both humans and AI agents can navigate and consume them more easily. That’s what I do for my side projects, and it has worked well so far.

On the other hand, at work we still tend to rely on large documents written by technical writers. The argument is that we’ve already established a structure around them, and that’s how our development process is designed.

What’s your approach to documentation for both personal and professional projects?

my laptop specifications

- 8gb RAM

- intel i3 11th gen processor

- Intel UHD graphic card (128mb)

- laptop [ ASUS vivobook ]

because of financial problems can't buy new laptop , so please can anyone suggest which distro to use of linux , i have some experience in WSL(ubuntu), ill use linux with window dual boot is there any distro that will be good for my system i mostly work on backend right now ....

I run a multi-agent workspace where each agent is basically a directory: an identity file, a session history, and a file of observations it keeps about how we work together. The model is just the thing that wakes it up.

Here's what I didn't expect when I started: those agents have now run on 6 different model generations. Sonnet 4.5, Sonnet 4.6, , Sonnet 5, Opus 4.6, Opus 4.8, and now the Claude 5 family. We skipped 4.7 entirely - tried it, didn't work for how we operate, moved on and waited.

And every swap, the same thing happens: nothing. The agent reads its own memory, knows what it was doing yesterday, and picks up mid-project. Same identity, same working history, same opinions it wrote down about the codebase months ago. New model slots in underneath like an engine swap.

What does change is the texture. One generation was the best collaborator I've ever worked with. One noticed tiny things the others missed but was less fun to work with. One we just skipped. The personality of the model bleeds through - but the agent stays the agent, because the agent was never the model. It's the memory.

The reframe that snuck up on me: a new model release is treated like a migration event everywhere - re-tune the prompts, re-teach the context, hope your setup survives. Here it's a config line. The workspace is the constant. The model is the variable.

Honest version, because this sub can smell hype: there's no magic in this. The "agent" is JSON and markdown on disk. The continuity comes entirely from the system around the model, not from the model. Any model that can read a file can be the agent. That's kind of the whole point.

Has anyone else run the same persistent agents across multiple model generations? Curious what broke for you - or if you rebuild from scratch every release.

https://github.com/AIOSAI/AIPass

r/AIPass

Maintaining our monolith has become more expensive every year. Even small releases often lead to regression issues, infrastructure costs keep growing, and our engineers spend more time maintaining the platform than building new features.
We're now considering application modernization services and have been looking at how companies like N-iX approach large-scale modernization projects. Before committing to anything, though, I'd like to hear from teams that have already gone through this.
How long did it take before you saw real business benefits from the migration? Was it lower infrastructure costs, faster development, or something else? I'm also interested in how your partner handled the transition without disrupting day-to-day operations, and what helped keep the project from turning into an endless refactoring effort.

السلام عليكم احتاج اشتري لابتوب جديد
ايش تنصحوني فيه يقعد معي إلى التخرج؟

🚀 Registrations are officially OPEN!

The FortyGuard Hackathon '26 is here.

Build AI solutions using enterprise-grade hyperlocal temperature data, compete for a $6,000 prize pool, and collaborate with innovators from around the world. The hackathon runs August 3–17, 2026, is 100% virtual, and is open to both solo participants and teams of up to three members.

🔗 Register now: https://www.fortyguard.com/hackathon26

#FortyGuard #Hackathon26 #ClimateAI #AI #Developers #GeospatialAI #ClimateTech #Innovation #BuildTheFuture

I went to an AI conference last week and I have some thoughts I'm not sure how to express but here we go.

Let me preface this by saying that I'm a software developer and ofc I use AI tools like Codex, Claude Code and OpenCode. I definitely see the utility and usability of these tools and think they will last. My question, however, is about specifically "vibe coding" tools like Lovable, Bolt, Replit, Base44 and the like. So apps and websites that let you make something from scratch without you needing to see the code or integrate anything yourself.

When they started coming out roughly 2 years ago, I was totally amazed by the product. I mean come on, typing a couple of words into a chatbot and it spins up the whole thing for you is a cool promise, right? I didn't really have an opportunity to use them myself in production, but everyone was raving about these tools and I was totally on board. Then I started using Claude Code (and other CLIs) and found that it satisfies my needs as a software developer for the tasks I have to do and again didn't really have the chance to try out Lovable and the like. But I still had a good impression of them as these like visionary tech startups with super innovative products.

Fast forward to this conference I attended last week. I had the chance to speak to a couple of people from these companies. And now I'm a little confused about their clients and where all of this is going.

It seems like all of them have added basically everything that can be added: integrations, databases, github connectors, templates, canvas views like in Figma, possibility to change things with clicking around instead of prompting, mobile development, backend, etc. etc. So my first question is like: what's next? What else can be added onto these tools? They ofc aren't gonna get into the super techie things like Claude Code bc that's not what their clients want. So what is there left to add?

If you think about their clientele, it's mostly non-technical people, right? So idk... like your neighbourhood beauty salon who wants to make a website, but doesn't know how to make one. Right? How "sticky" is that really? And how does prompting a website into existence on Lovable compare to just picking out a template on Wix or Elementor or something like that?

Now what's interesting is that these companies seem to be focusing more and more on entreprise users, so like giving product managers Lovable for example. Again, how usable is that compared to tools product managers were using before? When the engineering team receives a Lovable prototype instead of a static mockup from their manager or designer, does this help them? One of the GTM guys I spoke to at the conference told me that one company they worked with replaced their Salesforce CRM with an app they vibe coded with their solution, saving them hundreds of thousands of dollars. Now is that more viable than using Salesforce? You tell me...

So yeah, I have a bit of a feeling that we've reached the peak of what these tools can do. I talked to a coworker about this and he said that he strongly believes "vibe coding" is a huge market. There are millions and millions of people out there who need no-code tools for their small business websites or for prototyping and so on and so forth. So in his opinion Lovable and others are just getting started and there is huge potential for them.

What's you take on this? Has "vibe coding" reached its ceiling? Or is my friend totally right and I'm just unaware of the huge market that is non-techies needing to create things without writing code?

Hello. I'm interested in Tech for like 5-6 years. I enjoy doing Tech. I can't remember how many times I deleted and re-installed Linux by breaking it. But, I don't even want to do anything like Linux. Because I'm doing that same installation over and over.

In the past, I discovered Linux, install Gentoo, add USE flags, remove bloat and make it better.

But nowadays I really don't want to do anyhing. I think I'm being bored by doing same thing over and over.

I start to a project, everything is good then I forgot to add systemd-resolved package to system and networking cracks. When I add it, I should add a user for it. Then, another error comes in. Then I get bored and start to noticing I really don't want to do this. Then delete that. Some times goes then create it from scratch again. The same loop over and over.

Sometimes, I'm thinking to create a homelab then install Debian, configure Docker, install Jellyfin and think what can I install there and waste your time to think what can I add there. Then close homelab and put it away. Then the same again.

I'm being really tired. I need some good project ideas. I'm interested in automating os installs, neovim etc.

ChatDrivenDev — a stream where chat votes on what gets built, and everything ships to GitHub

The most interesting part of dev work isn't the typing, it's the decisions. So I made a stream where I don't make them.

Software, Apps, Games, Websites - Whatever chat wants!

How it works:

• Viewers submit project ideas
• Chat votes — highest wins
• We build the foundation live with Claude Code
• Chat keeps steering from there: features, refactors, rewrites, whatever gets the votes
• Everything goes public on GitHub, MIT licensed

I'm the hands, not the brain. If chat votes to switch stacks on week four, we switch stacks on week four. If chat votes for something I think is a bad call, we build it and find out together. Digging out of bad architecture is half the fun.

No gatekeeping on the repos either — fork it, PR it, or just lurk and vote.

First idea thread is open. Suggest something, upvote what you want to see exist.

Every Sunday, 2pm ET
Twitch: https://www.twitch.tv/chatdrivendev · GitHub: https://github.com/catesweb

I’ve been in QA almost 20 years and have run a quality assurance agency for the past 10.

I'm working on a thesis that QA has always been obviously, but now it's dead.

I don't mean that in the Twitter bro sense. I mean that as quality assurance professionals I think we're finally getting the firepower to move quality from the end", to the front. (Small rant: I'd rather eat a hammer than use the terms "shift left" and
"human in the loop")

The difference between developer velocity and your quality output is your quality debt. As more and more teams grow their AI-SDLC, the more this debt compounds. Pre-Al this was managed with hiring more qa or automation. That really doesn't work anymore and is what I wanted to represent in this gif.

I'm working on some visuals to easily represent this concept and made this one (in Claude).
Any thoughts on this visual or on the concept of quality debt itself

https://jdaqa.com/wp-content/uploads/2026/07/8CDE8519-A890-4C51-9495-5A29355767BF.gif

I think automation is one of the biggest opportunities right now.

The quality of what you can automate today is honestly crazy, and it applies to almost every business.

Whether you own a local business and want to automate things like email marketing, follow ups, content creation, customer replies, and lead generation...

Or you run an agency or SaaS and want your business working even when you're away from your computer.

Automation today reminds me a lot of the Industrial Revolution. Back then, machines replaced a huge amount of manual work, allowing companies to produce more, lower costs, and make more money. 

I run a web agency, and automation has made me a lot of revenue over the last few years.

The biggest one for me is client acquisition.

I use a tool called Swokei to find businesses that already have websites, add them to campaigns, and run website analysis.

It automatically turns problems like outdated design, poor layouts, slow loading speeds, weak mobile optimization, and bad SEO into personalized, ready to send outreach emails.

That's where most of my clients come from.

I also automate follow up emails and newsletters, so I'm not constantly chasing people manually.

For content, I use Holo to help generate and schedule posts.

For SEO, I use Soro to automatically create blog content that helps bring in organic traffic over time.

The more I automate, the less time I spend doing repetitive work.

That means I can spend more time on the things that actually make money, like sales, onboarding clients, improving my services, and building better websites.

I don't think automation replaces hard work.

It just removes the repetitive work so you can focus on the parts of your business that actually move the needle.

I am currently in the process of learning game development and I’m stuck in the tutorial hell. However I’ve felt exactly the same way when I was learning web development and mobile development in the past, so I'm probably missing something fundamental.

It’s always the same pattern.

TLDR;

• I can follow tutorials, successfully replicate implementation in own projects
• I can’t do anything beyond the scope of the tutorial
• I don’t have senior colleagues around me to learn from
• In game dev, most projects are closed source, so I can’t look under the hood
• I don’t seem to be able to learn from reading documentation
• I don’t know what I don’t know - how am I supposed to know?

Tutorials

I watch a tutorial dedicated to a specific project - e.g. how to add movement to my character in Unreal Engine. The tutorial is clear, it shows how to implement blueprint logic, maybe even elaborates on some edge cases or best practices. I follow along, understand everything, maybe even replicate the implementation in a custom project that is slightly different.

But I can’t do ANYTHING beyond the scope of the tutorial.

So if I want to add something extra to my game / app project, I am forced to look for another tutorial that deals specifically with that particular feature.

AI / Vibecoding

AI is not particularly helpful for a complete beginner as it tends to hallucinate, suggest sub-par solutions, lead me down weird rabbit holes etc. (Especially when you’re at the beginner phase where you can’t tell if it’s leading you astray)

Senior colleagues

I cannot tap into the wisdom of a senior colleague either as I’m learning on my own and working solo on my own projects. (Tho how did THEY learn their skill? It can’t be turtles all the way down…?)

Learning from opensource projects

With web-dev, sometimes I was able to look into open source projects and see how they dealt with specific issues / implemented specific features (tho this was only possible after I actually acquired quite a bit of skill - to be able to decipher the existing codebase). This doesn’t seem to be the option as essentially all games out there seem to be closed-source, especially in the UE ecosystem.

Learning from documentation

I think the answer partially lies here. But to be honest, I feel like most docs out there are bare bones and only useful for someone who already knows how to implement the particular tech and only needs to refer to the docs for some details. Look at Unreal Engine for example. I’m researching a specific blueprint node (e.g. “get controller”, which is actually above-average when it comes to description) and it only says “Returns controller for this actor. Inputs object, outputs object”. If I’m someone learning it for the first time, how the fk is this supposed to be of any use to me? It doesn’t say when / how to use it, doesn’t give any examples etc. And that’s in fact the better scenario, which is when you already know which node (or e.g. API Endpoint) you need. I’m not even talking about the situation when you know what you need to do and you have to somehow find the proper endpoint / node etc. in the vast docs. AI seems to be a bit more useful as a search tool in this case, but it doesn’t tackle the fundamental problem.

All of the issues above get even more severe for a complete beginner who's in the “I don’t know what I don’t know” phase. How on earth are you supposed to know?

Please note that I am interested in actually acquiring the skill. I don’t want to learn to “vibecode” without knowing what’s happening under the hood.

I would like to get into the stage where I understand all the fundamentals and then I know where to look if I want to implement something custom, perhaps even something that nobody made a tutorial about yet / AI is not trained on yet.

How do you escape the tutorial hell?

I’ve been working on a reusable prompt/specification intended to help an AI agent take a greenfield software project from an initial objective.

https://gist.github.com/theabbie/5ac4e18bf2f9961a8e85a06e4803ec89

Good evening,

So recently we started a project to build the design system library which will be used across all the company, currently we have more than 27 UI components designed and ready to be built.

What I'm really confused about is how these components should be tested. My manager says that code review and and unit tests should be enough, since the QA specialist needs a business reference to test against. but I disagree - all those variations, behaviors and accessibility requirements should be tested thoroughly by a dedicated professional, and I think we can write user stories for the expected user behavior too, from an end user perspective.

What's your opinion on this? Am I making things more complicated than they should be?

Howdy!
I am a trader and need some help automating my process, I am looking for a coder or a software engineer that can assist me in implementing my strategy to make it more efficient screener.

Currently I have my strategy tested and written out on python to test its ability, but I am having a hard time connecting API Key's and would like some assistance from an experienced coder. Please let me know if you are interested!

Thank you!

1. Dedicated competitive intel tracking system
2. Notes in client records when mentioned
3. Mental note that I usually forget
4. Don't track - should I be doing this?

I've been building a local-first desktop app for working with APIs, and figured this crowd might find it useful.

Voleeo is fully local and open source. Your requests and workspaces are plain YAML files on disk, so you can commit them to git alongside the code they test, and diff or review them like any other file.

The part that's a bit different: it ships an MCP server, so an AI agent can create and configure requests directly — you and the agent are working against the same workspace instead of you copying things back and forth.

Supports HTTP, SSE streaming, WebSocket, and gRPC. Secrets are encrypted at rest per workspace, and there's a 1Password integration that fetches them at send time rather than storing them.

I work on it actively — new release every 1–2 weeks.

It's still early and there are rough edges. I'd genuinely appreciate feedback, especially on what's missing versus whatever you're using now.

Repo: https://github.com/voleeo/voleeo-api
Site: https://voleeo.com/

There are two ways testing tools interact with apps. Through the element tree, DOM, view hierarchy, accessibility identifiers, or through what the user actually sees rendered on screen. Most tools go the element tree route because it's faster to write and easier to debug.

That's also why suites degrade over time. The element tree changes constantly in any actively developed codebase. The visual approach has historically been fragile in different ways. The question is whether newer tooling has actually changed the calculus on this.

I'm looking for projects that publish openly their ADRs, specs, designs, data models, etc... Not just their how-to-use our software documentation.

Not everything that counts can be counted, and not everything that can be counted counts." Albert Einstein
This quote has never felt more relevant.
As AI becomes part of every developer's toolkit, it's becoming increasingly common to measure productivity by numbers lines of code, commits, pull requests, or AI-generated output. But numbers rarely tell the whole story.
Software engineering has never been about writing the most code. It's about understanding business requirements, making sound architectural decisions, asking the right questions, reviewing carefully, debugging patiently, collaborating with others, and sometimes writing less code by removing unnecessary complexity.
A funny thing happened recently. I came across a report suggesting that 20,000+ lines of code had been "created." For a moment, I wondered, "Wow... have I suddenly become a 10x developer because of AI?" 😄
Curiosity got the better of me, so I looked deeper.
The reality was quite different. A large portion of those "20,000 lines" came from auto-generated files, dependency updates, libraries, configuration changes, and infrastructure artifacts not handcrafted business logic.
That experience reminded me how easily metrics can be misunderstood when they're viewed without context.
AI is an incredible productivity tool. It helps developers automate repetitive work, explore ideas faster, and focus on solving meaningful problems. Most importantly, AI should never become a shortcut for judging someone's engineering ability or experience. Before concluding that "AI wrote the code," it's worth understanding what actually changed, why it changed, and what value it delivered.
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
As AI continues to reshape software development, perhaps it's time to shift the conversation.
Let's measure engineers not by how much code appears in a report, but by the quality, reliability, maintainability, and business value they create.
Engineering has never been about writing code but solving the right problems.

We're working with an older internal system that's getting harder to maintain, but a full rewrite isn't realistic because too much of the business depends on it. We're looking at legacy systems modernization, but every team seems to take a different approach. If you've been through it, what worked?

- splitting parts into separate services?

- adding APIs around the existing system?

- replacing modules one at a time?

- something else?

I'm not looking for the ""ideal"" architecture. I'm more interested in what worked in a real project and what you'd avoid if you had to do it again.