Tag: AI

  • The New Software Team

    One of the things I used to emphasize in talks about DevOps is that no modern software of any significance is built by one person. Everything takes a team, so the foundation of version control becomes extremely important. We need a way to coordinate work across multiple individuals and communicate what changes are being made. This requires a strong foundation, and that starts with version control.

    In 2026, that hasn’t changed, but what has changed is the makeup of the team. No longer do I need a bunch of humans. In today’s world, with extremely powerful AI LLMs, we can have a team of AI agents that write code, often at a pace far exceeding that of human teams. However, they still need to coordinate and communicate and ensure their changes mesh together.

    In this short article on the rebirth of programming, the team is a team of n humans and m agents. N=1, and the architect, the coordinator, the project manager is the human (or a few humans). Code becomes less important, and the tests and other elements that describe and verify software become more important. Maybe even more important than today.

    I’d even go so far as to say the performance of the code might not matter in the short term. Since the cost of writing, or re-writing code, becomes lower and lower, when something doesn’t perform well, just spin off a new team of your agent coders who don’t need sleep, aren’t worse at development if they work more than 40 hours every week, and are always happy to tackle new work. It’s a project manager’s dream team. At least, in theory.

    That being said, the cost of writing this code isn’t zero. We see this rising every day, sometimes at a level that exceeds what we might pay human developers. That might change over time, but we certainly see some people spending more on tokens than salaries.

    And your agents do lose focus. Fortunately, you can fire them and hire new ones every day, or every hour. It’s like a team of characters in a game that respawn on demand to tackle the next challenge. There is still plenty of coordination and onboarding work for the manager. They will need excellent documentation and descriptions of what the code looks like, what needs to be done, and all of your guidelines on how to structure things. Lots of tests are needed, but your team can build them (with oversight).

    It seems like an amazing system, but we’re learning that excellent team leaders who are good architects are in short supply. And they can’t work long hours. Some early evaluation of these software managers seems to indicate that they can’t even work the full 8 hours for 5 days a week with a high level of effectiveness. They might not even be able to work half that amount of time.

    So is the falling cost of code going to produce more software? Likely, though perhaps with many more leaders needed to manage those teams. I can certainly see many more one person companies spawned during off hours, where one person can focus on their passion project, something completely separate from the work they are paid to do by someone else.

    It’s going to be fascinating to watch this work itself out across the next decade.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Limit the Blast Radius

    You still need DBAs (that know how to back up systems and test restores). If you think you don’t, or if you manager does, then perhaps they ought to read this piece on how an AI agent deleted a production database. This wasn’t the case of an agent just running around with sysadmin access to all resources, or a lack of tests that allowed bad code to flow through a CI/CD process.

    This was a system design that had a hole in it. An API call to change infrastructure that could change both staging and production. Not something an AI set up, but humans did. A hole from both PocketOS and the API vendor that allowed the AI agent to make the same type of mistake we’ve seen humans make. A mistake of not double checking, not verifying, not following the rules of getting a second set of eyes, even a second set of virtual eyes, on the code that could drop resources.

    Reading this, I can imagine this is how some of the AWS and Azure outages occurred over the last decade. Not the 2025/2026 AI inspired ones, but the 2010-2015 human mistakes that didn’t expect a change to have such a far reaching blast radius,

    You still need guardrails, for both humans and AIs. Don’t get slack and assume either truly knows what they are doing and deserves rights everywhere. Don’t assume that your guardrails were setup correctly. AI agents make great helpers. Use some read only ones to examine your setup and look for holes. If/When we get the next Claude Mythos model (or the equivalents from Google/OpenAI/etc.) have it look for precisely the types of holes that come from bad code that looks to reset, redeploy, or re-anything in your environment.

    We separate out roles for different people to limit the blast radius of the mistakes we inevitably make. AIs aren’t necessarily smarter or better than humans. Just faster. We need separate roles, separate rights, and governance for AI agents, precisely because they can make decisions faster than humans.

    There’s tremendous potential, but and tremendous danger in allowing anyone, or anything, too many rights in any organizations. RBAC, audits, and all the other things we implement to try and reduce the number of silly mistakes are still needed. At some point we’re going to see amazing social engineered emails, messages, XSS, and other items that are designed to fool the AIs just like humans have been fooled in the past.

    We need to ensure we set good guardrails and limits when that starts to happen. Or we’re going to lose control much quicker than expected.

    PS If you want a fun and slightly scary read on how AI could go sideways, I enjoyed The Final System recently, which made me not want to deploy any sort of AI agent beyond tightly scoped ones with very, very limited rights.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • What Can AI Really Do?

    I wonder how many of you have tried vibe coding something with an AI tool. If you haven’t, I certainly recommend it. I’ve been a bit amazed with a few of my AI Experiments, including my loading of a lot of inconsistently formatted data into a database for USD$5.

    To be clear, there’s plenty of vibe coding that might not be production-ready, but have you ever been handed code from a human developer you didn’t think was production-ready? Or deployed code like that? Certainly, AI could exacerbate the situation, but it can also spark ideas, ease (and speed) development in small ways, and tackle the backlog of things your org needs.

    Especially small tools.

    How big a concern or help will this be? I ran across an interesting article from a semi-technical person trying to build a text analysis tool. This is the type of thing we may do as database pros, but we wouldn’t have time to service every request for this assistance. There is a mixed bag of success in the piece, and a recognition that software developers have skills and knowledge that AI tools can’t necessarily duplicate in the hands of a non-pro.

    However, that’s where I think software engineers and database professionals have to learn to leverage AI tools to become more efficient, prove their worth, and, honestly, get more done without working longer hours. It’s also a place where you might guide users in producing some useful, but less mission critical software for themselves with AI. That might lower the number of requests I get.

    To me, that’s the direction I want to go with AI. More productive, less stress, and the same (or fewer) hours.

    What do you think AI can do for you? Let us know today.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • The Dangers of Dependencies

    Many of us working with databases know the problems of a single point of failure. We build HA/DR technologies into a lot of systems precisely because many of us know if the database goes down, a lot of stuff goes down. Broken software is easier to fix and rollback, but a broken database can be a much bigger problem.

    We also know an overloaded server doesn’t handle a workload well, hence our quest for well-written SQL code, but we often lose that battle with developers.

    In any case, as we move to a world where AI technology is used by many organizations, who often have a contract with a vendor to provide services, there is a potential issue. Imagine that you’ve setup workflows, maybe agentic loads and you depend on a company, say Anthropic, to provide those services. What if your organization gets banned?

    That happened to a company (reported on Reddit). A user got a note from Anthropic, but his entire organization got banned. That’s quite a dependency where a user in your company could cause an issue. In some sense, that’s like someone in your company sending an email that gets your organization’s email blacklisted or has Google/Microsoft/etc. cutting off access. Imagine the disruption there?

    Some of these companies providing AI services aren’t that large, and aren’t suited for the enterprise. Some of you are using vendors that might be contracting with these AI firms. Imagine your monitoring, DevOps, etc. service suddenly not working because they lost access to their AI services?

    I’d like to assume this doesn’t happen with the very large cloud vendors, but who knows. I’d like to think that not only enterprises, but even smaller companies don’t lose access because of the actions of one person. Or if they do, there’s any way way to get a response from customer service. However, I also know that Google, Amazon, and Microsoft have made it harder to get an answer from a real person.

    I didn’t talk about this recently when presenting on local AI models, but I think the future might be companies having more control over their AI tech, running them the same way we run servers in the cloud, in IaaS, with more effort required, but more controllable by the organization.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.