AI Impact on Open Source with Paul Everitt

AI coding agents are going to kill a lot of legacy open source. If maintainers don’t use AI to review and triage PRs, they’ll get buried in AI-generated junk. And with AI, it’s now faster and easier to just fork and build your own than beg gatekeepers to merge changes.

😀 Unpopular opinion: "bad AI output" is actually bad prompting. I've reviewed different models. The bottleneck is almost never the model. It's always the input. Fix your prompt structure. Fix your results. these are the steps that actually work: → Define role & context upfront → Specify the exact output schema → Include real input/output examples → Hardcode your constraints → Add chain-of-thought reasoning → State your full tech stack → Give broader system context → Use `contextforllm` to feed your codebase Don't blame the AI. Start engineering the prompt. #PromptEngineering #AIForDevs #LLM #GenerativeAI #SoftwareEngineering #AITools #DeveloperProductivity #TechTips #BuildInPublic #MachineLearning

AI is changing engineering faster than the frameworks available to measure it. What falls behind first isn’t the code. It’s the understanding of how the system responds. Here are five places where that gap shows up the most 👇

We’re living with AI slop now, and I don’t think we’ve fully processed what that means yet. AI can generate entire systems in minutes - APIs, frontends, databases, and on the surface, everything works. But underneath that, we’re starting to ship code that nobody truly understands, including the people who pushed it. I sat down with Bohdan Chaika, the creator of C-SLOP (C~) what started as a joke but quickly turned into a statement about where we are as an industry. One idea from our conversation really stuck with me and if AI is writing the code and AI is reviewing the code, then what exactly is the last line of defense? This isn’t about rejecting AI. It’s about being honest about the trade-offs we’re making and the responsibility that comes with it. We’re moving faster than ever, but that speed comes with a cost, and I think we’re just starting to see it. Full conversation here: https://lnkd.in/dmr48uRx

One thing that surprised me while building AI systems: The model is rarely the bottleneck. In most cases, performance issues come from: • Retrieval quality (RAG pipelines) • Context construction • Latency across multiple services • Poor orchestration between steps The LLM just sits at the center. It reminded me of backend systems: A single service is rarely the problem — it’s how everything connects. AI systems feel very similar: Less about the “intelligence” More about how well you design the flow around it. Still learning this the hard way, but it’s changing how I approach system design. #AI #RAG #SystemDesign #Backend #Engineering

Multi-agent AI pipelines are becoming real. But there's a problem: context loss compounds at every handoff. Agent A generates a design. Agent B writes the code. Agent C writes the tests. By the end, everything technically "works"... but the original product intent has quietly evaporated. It's the telephone game. For AI. We wrote about how this happens. 👇 (link in comments)

AI is everywhere right now. But the real challenge isn’t access - it’s too much information. Instead of jumping between tutorials, I started exploring NotebookLM to structure knowledge and focus on what actually matters. → Learn fundamentals → Understand real architectures → Build → Share 🎥 I break down my full approach here: https://lnkd.in/dTMfjTUt How are you approaching AI?

Vibe coding didn’t start with AI. Managers have been doing it for years. No specs. No requirements. Just a meeting, a feeling, and “make it happen".

An economist, a philosopher and an AI engineer walk into a bar… Concerned that I’ve been thinking about Agentic AI through the sole lens of technology, I wanted to broaden my perspective. What if I could sit down at a roundtable with a much wider range of minds and hear them discuss the implications of Agentic AI? So I decided to build a small experiment. Cue the Agentic Roundtable. Nine different personas take the same question and enter into a lively debate with each other. The goal isn’t consensus. It’s a clearer picture of a complex situation. If you’re curious too, have a look here: https://lnkd.in/g74M2TvP (It’s probably best on desktop) Would love to hear your thoughts.

How can we pace well with the amount of code being generated by AI? Before AI, an engineer wrote 250 lines of code in 3 days and we took 1 day to properly review the PR. Now AI writes 1500 lines and we spend 5 days on reviews. The math is pretty simple — it’s almost the same, plus the LLM token price. So what I’m seeing is yes, we increased development speed, but then we ate all the improvements in reviews, deployment, hotfixes, and going back and forth until we actually understand what we deployed. To me that looks like overcoming one bottleneck and creating another. I’m genuinely trying to understand — how do teams at your company deal with this?