Michael Kennedy

Visual Studio Code 1.109 positions itself as "the home for multi-agent development," so I put that claim to the test with a hands-on proof of concept outside the usual coding scenario. Instead of running one large, monolithic AI task, I broke an editorial formatting workflow into multiple subagents, each with a single responsibility, and added a final QA pass. The result was slower execution, but noticeably higher reliability on long, code-heavy documents. What stood out most was inspectability. Clear handoffs, visible intermediate results, and a timestamped report made it much easier to verify what happened and catch issues near the end of the file. This experiment reinforced that multi-agent orchestration is less about flash and more about quality control — a pattern that translates directly to production coding workflows where missed steps and silent failures are costly.

3

Software development is shifting so fast. Agent swarms are no longer a “watch this space” area, officially now mainstream in Anthropic.

1

Interested in learning more about Foundry Local https://foundrylocal.ai and how to build RAG-style systems that run locally? I’ve been exploring patterns for local-first retrieval, generation, and agent workflows, focusing on privacy, performance, and developer control. If you’re experimenting with RAG beyond cloud-only setups, these samples might be useful: • Local RAG – a simple, practical starting point for retrieval‑augmented generation running locally https://lnkd.in/e8DaV8ae • Local CAG – moving beyond classic RAG into contextual and agent‑driven generation patterns https://lnkd.in/eb5u_QXc • Local Hybrid Retrieval (ONNX) – combining lexical + vector search with optimized local inference https://lnkd.in/eh4mMwSi These projects are all about understanding the building blocks: local models, embeddings, hybrid retrieval, and how they fit into modern agent architectures with Foundry Local. If you’re curious about edge AI, local-first agents, or privacy-aware RAG, feel free to explore, fork, or share feedback. #AI #RAG #FoundryLocal #AgenticAI #LocalAI #EdgeAI #Developers

18

Don’t dismiss vibe-coding as the "bad" opposite of production-grade software. Both are valid responses to their operating context. They just sit at different points on the same optimization gradient. The real gap in the discourse is the absence of clear graduation thresholds. The moments where the cost of not adding “serious” software attributes flips from acceptable to risky. That tension is structural: -Vibe-coding optimizes for speed and fit under constrained responsibility -Traditional engineering optimizes for resilience and scale under diffuse responsibility Vibe-coded tools feel threatening to experienced engineers because it compresses the distance between intent and outcome, makes scaffolding optional, and de-emphasizes ritual and process. That reaction is understandable. The tension emerges when expectations on the software quietly change, but the operating model does not. Introducing a Vibe-to-Product Gradient framework: 1️⃣ Personal / Situational Utility “If this breaks, I shrug.” Where vibe-coding thrives: -Single user or small trusted group -Built for speed and local need -Manual fixes are acceptable -No external commitments Signals you’re here: -Inline logic, minimal scaffolding -Little to no logging -Security by access, not design -Zero-infra thinking Signals you’ve graduated: -Someone else depends on it -Usage becomes routine -"Can we rely on this?" appears 2️⃣ Shared Operational Tool “If this breaks, someone Slacks me.” ⚠️ The first real, and most commonly missed, threshold. This is also where invisible work creeps in. Signals you’re here: -Multiple users rely on it -Workflows get blocked when it fails -Fixes feel "small", but user interruptions aren’t New expectations: -Predictable failure modes -Basic logging -Backups or recovery -Clear ownership Signals you’ve graduated: -Exec visibility -External stakeholders -"This can’t go down" appears 3️⃣ Business-Critical Capability "If this breaks, we miss money, reputation, or commitments". The danger zone for vibe-coded tools - because obligations have changed. This is when engineers get twitchy, and ownership should be transferred explicitly. Signals you’re here: -Financial or compliance impact -Informal on-call expectations -Trust is assumed, not optional New expectations: -Observability (logs, metrics, alerts) -Security and auditability -Change control -Explicit ownership and SLAs Signals you’ve graduated: -Multiple teams -Contractual guarantees 4️⃣ Platform / COTS-Equivalent “If this breaks, we’re on the hook.” At this point, you’re either: -Rebuilding half a SaaS platform internally, or -Paying someone else externally to absorb years of operational, legal, and organizational entropy. This is where COTS earns its keep - through liability transfer, not features. Key Takeaway: Don’t dismiss vibe-coded software as "not production-grade". The real risk to manage is when expectations keep graduating, but the tooling - and operating model behind it - doesn't.

6

Continued thoughts on Per Aspera 001: The Return to the Guild As I’ve had more time to reflect on Dan Goldin’s Per Aspera 001 and this article from GitHub’s Branching Out_ channel—https://lnkd.in/gkp3u3TU “Why Developer Expertise Matters More Than Ever in the Age of AI”—I’ve been meditating deeply on the future of education, the ancient patterns of apprenticeship, and the soul of software engineering itself. We are, I believe, living through a strange paradox. On one hand, AI promises to accelerate development, automate boilerplate, and optimize workflows. On the other hand, the core of what makes a developer excellent—clarity of thought, principled design, architectural foresight—cannot be automated. These are not just skills. They are virtues. And virtues must be cultivated. The article rightly points out that developer expertise is becoming more valuable, not less, in this new age. I agree—but I’d go even further. Expertise is not just about efficiency or productivity. It is about craft. And that’s where our current institutions have failed us. The industrial education system, with its pre-packaged curricula and endless credentialism, has little to say about mentorship. About learning by osmosis. About failing nobly under the watchful eye of a master builder. The great developer is not born from YouTube tutorials or bootcamp sprints. They are born, like the blacksmith or stonemason of old, through the sacred rhythm of apprenticeship. I believe it is time to return to the guild. A place where elder technomancers teach the next generation not just how to code, but how to think. A place where principles like SOLID, Clean Code, and the Twelve-Factor App are passed down not as checklists, but as living traditions. A place where engineers are trained not only to build, but to bear the moral weight of what they build. Alternative education models—similar to the technology academy mentorship program I’ve experimented with in the past—point toward this future. A future that’s slower, deeper, and more relational. A future that values wisdom over trend-chasing, and character over hustle. In the end, this is the invitation of Per Aspera: to take the harder path. The path of craft. Of community. Of the sacred return to form. Because while AI may change how we build software, it cannot change who we are while building it. #PerAspera #SoftwareEngineering #DeveloperLife #TechLeadership #AlternativeEducation #MentorshipMatters #Apprenticeship #EngineeringExcellence #AIandDev #DevCommunity #FutureOfWork #SOLIDPrinciples #CleanCode #MoralTech #HumanCenteredAI #IndieDev #EngineeringWisdom #CodeAsArt

9

4 Comments

Nearly 100% of the code in the new platform I'm working on is written by agents. Not a POC or experiment. We've been doing this for five months and are rolling to production now. Short version of what I've learned: TDD goes from nice-to-have to non-negotiable. Line-by-line review of 30k lines a day puts you back at human velocity, so you need quality defense in depth — pit robots against robots. And your new coding partner is neither your replacement nor a slop machine. Full post: https://lnkd.in/gKANJcMG

38

9 Comments

During the "Ambient Agents" meetup last week, Brace Sproul gave us a walkthrough of Open SWE, a coding agent built on Langgraph. Open SWE monitors GitHub issues. When it gets a new one assigned, it kicks off a multi-agent architecture with a Manager, Planner, and Programmer. It can receive messages from users at any time during the process and incorporate them into the state. Check out the slides for diagrams explaining each agent: https://lnkd.in/g3PnNHqG And the code: https://lnkd.in/gY68TKYy I found the takeaways really interesting: * Summarization is hard: Especially with code changes that can get quite long, you literally can't send the entire context history to the LLM, and highly detailed old diffs may distract it. IIRC, the agent sends the last 20 messages, and summarizes the changes before. * Agentic > hard coded: Open SWE tends to use the agentic approach of "here are your tools, pick which one to use" for almost all tasks. Except for one.. * Explicit error handling: When an error happens, Open SWE stops everything and focuses on resolving the error. Otherwise, it could get too far afield and be unable to get back to a good place to solve the error. (Hopefully I didn't mis-represent anything I heard!) #Langchain #Langgraph

93

3 Comments

If you don't have "taste", then your LLM usage will generally output slop. I have a pretty good taste for code, so I'm able to quickly evaluate LLM generated code to make sure the parts I care about aren't slop. I have a decent taste for writing, so I write most things myself and just use LLMs for editing and critique. I'm OK at evaluating design, but no where near as experienced as I am with code. So I'm actively leaning into building my taste in that area. What other areas are important to develop taste in as a product builder? Business acumen taste? Architecture taste? Any tips for developing taste so you can turn slop into something tasty? #slop

13

2 Comments

I thought this was a good and very reasonable talk by Eleanor Millman on how to prioritize projects for a platform engineering team: https://lnkd.in/gaYtUHRH A few insights I took from it: - Unlike product features which can be more directly tied to revenue, platform engineering work is a couple steps removed. But that doesn't mean it's unimportant! Far from it, platform engineering projects can make everyone at the company more efficient, able to produce higher quality software, etc. - While "urgency" is always going to be a factor, you don't want to just be putting out fires, you want be able to prioritize work which is "high impact" ... even if that impact isn't felt immediately. - Good rule of thumb: prioritize "highest impact for lowest effort". - The talk has some ideas on what factors to choose for impact, and how to blend them. For instance "speed of development" is one factor, "cloud cost optimization" might be another. The weighting of different impact factors can change over time, depending on the needs of the business. I would say that a lot of companies don't have much methodology here but I can really see the value in codifying it. You can always change the methodology or the weighting if it's spitting out results that don't pass the smell test or you really feel it is leading the company astray. Clarity can give the org more freedom to put resources behind projects that would otherwise never be taken on. When things are unclear, prioritization still happens implicitly, but the decisions tend to be a lot more random and fear-based and the org is worse off as a result.

15

3 Comments