Skip to main content

2 posts tagged with "Developer Tools"

View All Tags

Developer Experience Insights from the State of AI Survey

· 8 min read

Watercolor illustration of a developer surveying an AI landscape of models, clouds, and tools from a hilltop desk

I love the State of AI survey results put together by Devographics. I participate every year and I genuinely look forward to the results — wondering how closely my own experience lines up with the industry, and what signals I can find to affirm or change direction. This year's report is based on over 7,000 respondents and there's a lot to dig into. I'm going to call out a few areas I find most interesting, but please explore it yourself — the data rewards time.

Model Providers vs. Models vs. Runtime Location

You can read a lot into how a survey is designed, not just the results. One area I've been focusing heavily on in the last six months of my own development is what I call model value — using the right model for the right purpose.

Most survey respondents (and most headlines) are focused on cloud models from the big-name vendors. Anthropic and OpenAI are obvious winners in that category, and the survey backs that up clearly. But I'm interested in extending that conversation to include model catalogs and model runtime location. That means places like HuggingFace, NVIDIA, Ollama, and Azure AI Foundry.

This isn't because I work at Microsoft — though I do appreciate where Foundry is going, especially its commitment to making the full breadth of the model ecosystem accessible in one place. It's because I genuinely appreciate the diversity that comes from having hundreds of models with different strengths, sizes, and licenses available to me. They all have value.

I also appreciate that I can do real work on my local machine with a downloaded small language model (SLM) and not worry about token costs. That's not a fallback strategy — that's a workflow. Tools like Azure Foundry Local make it straightforward to run these models on your own hardware. For certain tasks: summarization, local code review, quick drafts, the SLM on my laptop is fast, free, and private.

The survey supports the idea of local AI, though it's tucked in a back corner under Usage: Local AI — you have to go looking for it. I expect that section to grow substantially. As more developers want to maximize the compute they already own and reduce API spend, they'll branch out into other model providers and runtime locations beyond the cloud. Local-first isn't fringe thinking anymore.

My prediction: Next year's survey will have more questions that clearly differentiate model vendor, model provider, model runtime, and model cost. These are four distinct dimensions and right now they're blurred together.

Risk, Reward, and the Agents Question

The survey also asked for opinions on broader concerns — whether AI poses an existential risk, whether people are worried about job security. I found those questions interesting but not surprising in their results. What will be interesting is how those answers shift next year as the technology matures and the hype cycle normalizes.

The section I'm most confident will grow and evolve is Agents and Assistants. "Agents" can mean a lot of things depending on who you ask. In my own use and development, an agent is something that completes well-defined work autonomously — not a chatbot, not a suggestion engine, but a teammate with a scope.

A year ago, that meant LangChain and LangGraph. Those are still valid tools. But now the agent framework landscape includes many more options, including the GitHub Copilot SDK, which I've been using heavily.

One of my favorite tools in this space is Squad — a team of AI agents, each with different expertise and a different work surface, collaborating to help me complete work. Squad isn't just a productivity tool. It's changed how I think about AI and how I interact with it. I went from asking an AI a question to managing an AI team with defined roles. That shift in mental model matters.

My prediction: Next year's survey will have significantly more questions about agent frameworks — not just "do you use agents" but what frameworks, what patterns, what governance.

New Tools Adopted from AI's Demands

Here's something the survey doesn't capture yet but I see every day: AI hasn't just changed how I write code — it's changed what tools I need to write code.

Take Dev Containers as the clearest example. Instead of installing tools locally and hoping versions stay consistent, I define my entire development environment as a Docker container — declarative, reproducible, isolated. I run these containers as development environments on my own compute. Every project gets exactly the dependencies it needs, and nothing bleeds between them.

I didn't adopt Dev Containers because it was trendy. I adopted them because AI agents need consistent, predictable environments — and they need compute that doesn't stop. When you have multiple agents running builds concurrently, or a cloud agent like GitHub Copilot provisioning its own environment from scratch, you need something better than "I hope the right version of Go is on PATH." A devcontainer.json defines exactly what's available, every time, no drift. The agent gets the same environment I do.

The same pattern extends to DevBox — the key difference is where the compute lives and whether it shuts down. Dev Containers run on my own machine, always available, always under my control. DevBox moves the environment to cloud compute that can be spun up and torn down on demand. Both solve the same core problem — declarative, reproducible environments that agents can parse and modify — but the tradeoff is local persistence versus elastic cloud resources. These aren't tools I sought out for their own sake — they're tools that became necessary because the work exposed the fragility of manually-managed environments.

My prediction: Next year's survey will start asking about developer environment tooling in the context of AI — not just "what IDE do you use" but "how do you manage environments for AI-assisted development?" The infrastructure layer is shifting underneath us, and the tools we adopt next will be shaped by what AI needs to function well alongside us.

What's Missing: The Survey's Blind Spots

This is the part I think about every year with Devographics surveys — the sections I expected to find but didn't. A few stand out.

Fundamentals: MCPs, skills, and pipelines. Model Context Protocol (MCP) has become the connective tissue of modern AI development — it's how tools talk to models, how context flows between systems, how you compose AI capabilities. It wasn't in the survey. Skills and pipeline composition weren't either. These are core developer experience concerns right now.

Thought leadership and learning sources. Who are developers reading and listening to in order to keep up? What communities are they in? Is large language model / small language model the only path people see toward AGI, or are there other architectures getting attention? These questions would reveal a lot about how the community sees the next few years.

Security. AI in the developer space has huge and immediate security implications — prompt injection, model poisoning, data exfiltration through context, supply chain concerns with models themselves. This deserves its own section in a developer survey.

My prediction: Next year's report will address most of these gaps. I've seen Devographics do exactly this with previous surveys — State of JS, State of CSS — where year two and three add the depth that year one reveals is missing. The State of AI survey is following the same natural progression, and that's a good thing.


If you haven't read the State of AI survey yet, carve out an hour. Look at the cross-tabs, read the opinions section, and notice what questions they asked and didn't ask. The shape of the survey tells you as much as the answers do.

I'll be participating again next year and hoping to see my predictions validated — or proven wrong, which is honestly just as useful.

GitHub Account Cleanup: Audit, Archive & Remove Stale Repos

· 5 min read

My end of year project is a GitHub account repository-cleanup tool to provide safe, repeatable auditing and cleanup for my GitHub accounts. I also wanted to create a catalog of my active repos. This repo focuses on repository-level cleanup (archive/delete/catalog), but the same audit run can help you discover candidates for cloud-resource reclamation and CI/workflow maintenance.

When to use this project

  • Periodic account maintenance (end-of-year or scheduled audits).
  • Before publishing a portfolio or transferring repositories.
  • When you want a reproducible audit with a dry-run-first approach.

Functionality included in GitHub account cleanup

My TypeScript project cleans up my account in the following way:

  • Archive stale repositories,
  • Detect and delete empty repositories,
  • Remove forks,
  • Generate repo descriptions and topics with LLM and update repos with that info,
  • Generate a catalog of active repos for publishing.

High level architecture

1- primary entry is scripts/run-all.sh 2- workflows are optional 3- gh-cleanup calls github-rest and llm-completion 4- outputs go to generated/

The high-level architecture of the npm workspace monorepo:

  • packages/gh-cleanup — CLI commands and orchestration: categorization rules, scoring, reporting, and the runner that coordinates dry-run and apply flows.
  • packages/github-rest — GitHub REST helpers, typed endpoint wrappers, and shared network utilities.
  • packages/llm-completion — LLM/AI utilities: prompt helpers, request wrappers, retries, and response sanitization used by the describe step.
  • generated/ — Example outputs created by dry-run executions: catalog.md, active.json, descriptions.json, summaries, etc.
  • .github - Workflows and prompt files.
  • scripts - Top level script to clean up GitHub account, also used by

Prerequisites

This repo can be opened with Codespaces or locally with .devcontainer/devcontainer.json. The development container has all the developer setup for this project including Node.js. Once you have the repo open with the environment, create a GitHub token and an OpenAI key and an LLM model. Set these values in the root level .env.

  • A GitHub token in GH_TOKEN (classic PAT with repo scopes; delete_repo only required for destructive operations such as deleting a repo.)
  • OpenAI key for LLM generation of repo descriptions and topics and an LLM model. I used 4.1-mini from Azure OpenAI.
GH_TOKEN=
GH_USER=YOUR_GITHUB_USER_ACCOUNT
OPENAI_API_KEY=
OPENAI_ENDPOINT=https://RESOURCE-NAME.openai.azure.com/openai/deployments/MODEL_NAME/chat/completions?api-version=API_VERSION
OPENAI_MODEL=gpt-4.1-mini
OPENAI_TEMPERATURE=0.2

Install and build dependencies

The root package.json uses npm workspaces to control and access all the packages in ./packages. Use the root package.json scripts to install and build the tool.

npm install
npm run build

Try out the tool

One-line run examples

  • Remove forks (dry-run):

    npm run start -w gh-cleanup -- remove-forks
  • Archive stale repos older than a year (dry-run):

    npm run start -w gh-cleanup -- archive-stale-repos
  • Delete empty repos, no PRs, no commits, size is 0 KB (dry-run):

    npm run start -w gh-cleanup -- delete-empty-repos
  • Categorize repos (fetch languages + README, output Markdown):

    npm run start -w gh-cleanup -- categorize-repos --fetch --output=md --out=generated/catalog.md
  • Summary (write generated/summary.md):

    This creates the final active list of repos in a markdown table. I'll use this in my dfberry.github.io website to find projects with specific code, configuration, or CI.

    npm run start -w gh-cleanup -- summary --summary-out=generated/summary.md

Full run

Once you understand what the tool does, use the ./scripts/run-all.sh to clean up your GitHub account. I used my personal dfberry account to test while building. Now that it is complete, I'll use it on my work diberry account for Microsoft.

npm run run-all:apply

The apply means empty repos are deleted and active repos are updated for description and topics.

AI-assisted development

I use AI tools (Copilot, Ask/Plan/Agent) to speed development while keeping human oversight. I commit frequently and review AI suggestions line-by-line. Choose models and session types (local, background, cloud) deliberately to control cost and behavior. Never let AI run unattended on critical changes—use dry runs and manual tests. I scaffold the repo, add features incrementally, and document decisions so I can return later. Copilot helps with comments and diagrams, but I always review and adjust its output.

Next steps

Cleanup goes beyond removing unused repositories. When tidying a personal or org GitHub account you may also:

  • Reclaim unused cloud resources referenced by projects (e.g., old deployments, test clusters, or storage buckets).
  • Remove or archive unused repositories that are forks, abandoned, or no longer relevant.
  • Find and fix failing or stale GitHub Actions workflows (update action versions or workflow syntax) or remove workflows that are no longer useful.
  • Update CI matrices and runtimes (programming language versions, OS matrix entries) to reduce CI cost and avoid testing very-old combinations.
  • Bump pinned GitHub Action versions and dependencies to address deprecations and security fixes.