Earlier this year, I was brought in as a delivery process consultant at a small software company.
The goal was straightforward: help them use Jira as a single source of truth for improving internal delivery visibility and reporting.
I was brought in because I had an unusual combination of experience. I've spent about 40 years in software development, in roles ranging from developer and tester to product manager, project and program manager, and Agile coach. And I've spent many years working deeply with Jira -- not just using it, but configuring it to support how software organizations actually work.
My job was to architect the solution: define the workflow, standardize the issue types and fields, establish the information model that would allow the company to track multiple workstreams simultaneously and create automations to minimize manual data entry.
I wasn't working directly with the development teams or managing their projects. I had to envision how I would organize the work if I were responsible for delivery across the company, and then design Jira to make that possible.
That part was familiar territory.
What happened next wasn't.
The reporting requirements changed everything
Setting up the basic Jira structure was relatively straightforward.
The harder part was reporting.
The company wanted Jira to be the source of truth, but that meant it had to support much more than simply showing individual tickets. They needed reporting that connected work in Jira to management-level visibility across multiple simultaneous workstreams, with enough data quality checks to make those reports trustworthy.
I could have looked for Jira plugins to solve some of these problems, but I was reluctant to introduce them casually.
A plugin becomes something the company has to live with after the consultant leaves. They have to pay for it, understand it, and maintain whatever process grows around it. And before adopting one, you really need to do some due diligence. Some Jira plugins are produced by substantial software companies. Others may be produced by two guys in a garage with a dog who might not be around in 6 months. As with any software, you need to understand what you're buying, whether it will continue to be supported, and whether it actually does what you need.
That evaluation itself takes time.
So for several of the reporting needs, I went in a different direction.
I started building the reports myself.
That meant Python.
At first, I wasn't really thinking of this as a software development gig. I was trying to solve reporting problems: read data from Jira, perform calculations Jira wasn't doing for us, and produce useful outputs in places people already worked -- Google Sheets, Google Slides, and Slack.
But those report requirements kept getting more sophisticated.
And I spent far more of the engagement than I initially expected designing the reports, writing specifications (and the complex business logic), working through edge cases, testing the reports, and figuring out how to make the whole thing reliable.
What became particularly interesting was how I did that work.
I started creating separate AI roles -- a Business Analyst, a Developer, a Code Reviewer, a Tester, and sometimes a presentation designer -- and I acted as the person connecting them.
I started building an AI development team
I didn't start out with a grand plan to create an AI development team. It evolved as the work became more complicated.
I would create a separate chat for each role. One was my Business Analyst. Another was the Developer. Another was the Code Reviewer. For some of the reports and presentations, I also had a separate role focused on visual design.
Sometimes I used ChatGPT for a role. Sometimes Claude. Occasionally, Grok and Gemini. Later I used other tools as well.
I deliberately kept the roles separate.
In fact, I didn't tell one AI that the other members of the "team" were also AI. The Developer might know that something had come from "my BA," but not that the BA was another chatbot.
That made me the person in the middle.
Most of the work started with the specification. I would think through what I wanted to build, discuss it with the BA, go back and forth over questions, and eventually get to a detailed design and specification. I would provide rough wireframes to visualize what I was thinking. We would iterate until I thought it was reasonable.
Then I would take that specification to the Developer and Code Reviewer. They would raise more questions -- sometimes things I hadn't considered. Some were functional. Some were technical. We would work through those, make decisions, and then the code would be developed and reviewed.
I rarely read the Python code itself. I could. I used to be a developer. But I didn't. Instead, I relied on a separation of roles. The AI Developer was told to implement the specification. A separate AI Code Reviewer was told to review the code against that same specification. I asked both to create tests, and then I did my own functional testing afterward. It wasn't exhaustive, but I wasn't simply accepting whatever the Developer produced.
Every handoff went through me.
If the BA proposed something I didn't agree with, I corrected it before the Developer saw it. If the Developer proposed an approach that didn't seem right, we resolved that before moving on.
So I really was the human in the loop.
It could be exhausting.
It was also exhilarating.
I had spent years as a product manager imagining systems and working with development teams to build them. This felt surprisingly familiar. I could envision what I wanted, describe it, challenge the proposed solutions, and work through the details with a team that could move extraordinarily quickly.
The difference, of course, was that everyone else on the team was AI.
AI knew more than I did. But that didn't mean it was right.
One of the most important things I learned was that the AI often knew more than I did.
Certainly more about Google Drive integration, Slack integration and certain technical details with Jira. Often more about some of the intricacies of the Jira APIs (though I was the one that explained how to properly page through pages of data), Google APIs, race conditions, error handling, and other technical details.
I had no idea how to set up a Google Service Account. It walked me through the steps and helped me document them.
At times, the AI had a tendency to make assumptions instead of digging deeply enough into how things actually worked.
That caused problems.
Early on, for example, the AI made assumptions about the Jira workflow and how some important fields were configured. The AI assumed, incorrectly, that things were configured in a standard way instead of first asking how the system had actually been configured. Those assumptions sounded perfectly reasonable. Some of them were wrong. It helped that I understood Jira pretty well.
More than once, a Developer or Code Reviewer suggested an approach that sounded good initially, but something about it bothered me.
Sometimes I couldn't immediately explain exactly why.
I just knew enough about the system -- and had been around software development long enough -- to think, "No. I don't think we want to do it that way."
Then we would dig deeper.
Often there was some dependency or interaction the AI hadn't considered. The proposed solution might work technically, but not with the way this particular Jira implementation worked, or not with another part of the reporting system, or not with a decision we had already made elsewhere.
Obviously, the AI had an enormous amount of knowledge available to it. It could draw on documentation, examples, and technical discussions and synthesize them much (much, much) faster than I could. But knowledge wasn't the same thing as experience.
What I could do was recognize when something didn't feel right.
And because the AI usually presented both good and bad ideas with the same confidence, I learned very quickly that I couldn't simply accept an answer because it sounded authoritative.
I learned to own the specification
Most of the work wasn't actually writing code. The AI, when provided a detailed specification, produced the code in minutes.
The real work was developing the specification.
I would start by thinking through what I wanted the system to do. Then I would work through it with the BA. We would go back and forth, section by section. The BA would ask questions. I would answer them, rewrite things, add detail, or sometimes change my mind.
Eventually, we would have something detailed enough to take to the Developer or Code Reviewer.
Then they would ask a different set of questions -- usually more technical ones. They might raise race conditions, edge cases, API behavior, or suggest a different way of implementing something.
That usually made the specification better.
But it also created another problem.
I began noticing that if I let the AI edit the specification directly, it would sometimes make small changes I hadn't asked for. Usually they sounded reasonable. Sometimes they were even improvements.
But occasionally it would add something that I had never decided, or subtly change the meaning of something that had already been settled.
I started thinking of that as AI slop (a term I first heard on a podcast).
Not necessarily bad writing. More like plausible material that appeared because it fit the pattern of the document, not because I had actually decided it belonged there.
So eventually I made a rule: the AI could suggest changes, question things, challenge decisions, and help me think through alternatives.
But I owned the specification.
I made the actual edits.
That was tedious at times, especially as the specifications became longer and more detailed. But I trusted the result much more because I knew every requirement in the document was there intentionally.
And because the specification was what ultimately drove the development, review, and testing, that mattered a lot.
Cursor changed the delivery process
Early on, my development workflow was pretty crude. I was running Python scripts manually in a local command window, and nothing was checked into version control.
Later in the engagement, I started using Cursor. That changed the operational side of the project completely.
Beyond reading the codebase directly, the AI walked me step-by-step through setting up GitHub integration and guided me through making my first real pull request. It even helped me package the tools so someone else on the team could pull the repository and run them without my involvement.
Moving from manual local scripts to structured, version-controlled software was a huge milestone. But even with that smoother workflow, the underlying rule stayed the same: the AI could manage the mechanics, but I still had to own the specification.
What I left behind
By the end of the engagement, this had become a very different project from the one I originally expected.
I left behind several internal reporting tools, along with specifications, testing notes, operational documentation, and Jira process documentation.
The tools supported different kinds of internal reporting, including delivery visibility, team execution metrics, support-related reporting, and data quality checks.
They weren't enormous systems. But they were real software being used to solve real business problems.
And I had built them without becoming a Python developer.
That still feels a little strange to say.
I'm 63. I started programming when COBOL, Pascal and C were normal parts of the technology landscape. Most of my career since then has been spent closer to product management, program management, delivery, process, and system design than hands-on coding.
Yet here I was, decades later, building software again.
Not because I suddenly became an expert Python programmer.
Because the tools had changed.
I had already used this approach once before
This wasn't actually the first time I had used AI this way.
While writing my memoir, I had more than 1,000 pages of records, journals, notes, and other material to work through.
AI was enormously helpful in organizing that material, finding patterns, and helping me think through structure.
While I didn't have a BA or Developer, I did use several personas -- Chief Editor, Copy Editor, Beta Reader, Cover Designer.
But I treated the final writing much the same way I later treated the software specifications.
I kept ownership of it.
I was too concerned that the AI might change a word, smooth something over, or subtly alter the meaning of something I had written intentionally.
So it could help me organize, question, compare, and suggest.
But the final words were mine.
What I took away from it
I came away from this engagement with a different view of what AI can do for someone with a lot of experience.
The AI allowed me to apply what I already knew in ways I couldn't have done by myself.
I understood software development. I understood product and delivery. I understood Jira. I could envision the systems I wanted to create and recognize many of the consequences of the decisions we were making.
The AI brought capabilities I didn't have.
It could write the Python. It knew APIs and libraries I didn't know. It could review code, suggest test cases, and raise technical questions I might never have thought to ask.
But that didn't mean I could turn over the work and walk away.
If anything, the experience convinced me that judgment becomes even more important when the tools become this capable.
The AI could give me an answer very quickly. My job was to decide whether it was the right answer.
Sometimes that meant asking another question. Sometimes it meant challenging an assumption. Sometimes it meant saying, "No. That doesn't make sense. Let's look at this again."
And sometimes I was wrong.
But I had enough experience to know when something deserved another look.
Maybe that's the part of AI that interests me most at this point in my career.
After 40 years in software, I don't need AI to replace what I've learned.
I can use it to do things with that experience that I couldn't have done before.
AI Disclosure
Yes, I used AI to help write this post.
I started by writing a very long description of the engagement and providing source material for context. Then I worked through the story with AI, discussed what belonged in the article, agreed on an outline, and used that to develop a first draft.
After that, I revised it section by section.
Which is pretty much the same process I described in the article.
The AI helped organize, suggest, challenge, and draft.
I decided what stayed.
And honestly, I still find this remarkable.
When I was young, the idea of having a tireless, knowledgeable assistant available whenever I wanted -- someone I could talk through an idea with, ask questions, challenge, and use to help turn a pile of thoughts into something coherent -- would have sounded like science fiction.
Now I have one.
How freakin' cool is this?