{"slug": "writing-production-quality-code-with-ai", "title": "Writing Production-Quality Code with AI", "summary": "Curtis Poe, a consultant and AI advisor, has developed a method for writing production-quality code using AI, which he calls PAAD (Prompt, Analyze, Architect, Develop). Poe argues that while this approach requires more tokens upfront, it reduces total cost of ownership by producing higher-quality code that is less likely to be rejected. He has published a free tutorial and open-sourced the PAAD skills on GitHub to help developers adopt this engineering-led process.", "body_md": "My apologies if this reads more like a blog post than a tech article, but knowing how this approach was created makes it easier to understand why this works. I can't possibly replace the training I do with a blog post, but I'll give it my best shot.\n\nYes, you can write production-quality code with AI. It’s actually straightforward, requires engineering discipline, and while it will cost you more tokens up front, you get higher quality code that is less likely to be kicked back for rework. Total cost of ownership drops, but unfortunately, many companies still focus on unit costs.\n\nIf you want to skip how this was created, [you can read my free tutorial](https://curtispoe.org/paad/) (no ads, no registration) and check out [the PAAD skills on GitHub](https://github.com/Ovid/paad). Please star the repo if you find it useful.\n\nAbout two years ago, I found myself in the curious position of regularly advising the C-suite about AI. To my surprise, I was viewed as an “AI expert”, though for the first time in many years, I felt imposter syndrome creeping back. I had written software with AI and I had built chatbots, AI-image generation pipelines, vector-database backed semantic search engines, fine-tuned models, and even designed an agent architecture for a client, despite agents being relatively new (and promptly lost the contract to build it because the design was detailed enough that the client assumed they could do it in-house; such is the life of a consultant).\n\nBut I didn’t *feel* like an expert.\n\nWorse, when you're sitting on leadership, you’re often looking where things will be two to five years down the road. The skills that got you to that point slowly start to atrophy, replaced by the new skills you need for your new role. At the pace at which AI was advancing, my conclusion was that this would be a disaster. Even if I *was* an expert, I wasn't going to remain one for long.\n\nDue to the nature of what I do, I find myself constantly flying from country to country, training, consulting, troubleshooting, and so on. I’m often sitting alone in a hotel room, after the nightly video call with family. I needed to put that free time to use.\n\nAI is advancing rapidly and one of the biggest pain points is “AI slop” (that largely a rebranding of technical debt; keep that in mind). You’ve possibly seen this [somewhat viral post from a founder](https://www.reddit.com/r/vibecoding/comments/1su03dk/vibe_coded_for_6_months_my_codebase_is_a_disaster/), describing an app they vibe-coded over six months:\n\nthe app works. users are happy. revenue is coming in.( that’s actually the only good part)*\n\nbut i just tried to onboard a dev to help me and he opened the repo and went quiet for like 2 minutes. then said “what is this.”\n\nThis sums up the problem. We’re not supposed to be writing software entries for [the Bulwer-Lytton contest](https://www.bulwer-lytton.com/about), yet here we are.\n\nSo to keep my skills sharp, [I decided to conduct an experiment](https://curtispoe.org/articles/why-i-am-no-longer-reading-the-ais-code). If I write some C, I don’t look at the compiled assembly code. If “English is the new programming language,” why should I read the generated code? I kept very quiet about this experiment, because I knew it was mad and I’d get ridiculed, but I wanted to see if I could produce production-quality code without ever writing or reviewing the code while it’s being developed.\n\nSide note: by “production-quality”, I just mean code that an experienced engineer can take and say, “yeah, I can work with this.” I’ve been writing software for decades and human-generated code often fails this test. But my process is engineering-led, so **you** still need to consider correctness, security, operability, observability, performance, recovery, etc.\n\nNone of what I advocate argues that we can hand the reins over to AI.\n\nMy hypothesis was simple. I would fail to write production-quality code but I would learn so much through the process that I could use these learnings to share with others.\n\nMy hypothesis was wrong. I didn’t fail. Yes, I failed *a lot* at the beginning, but I kept learning. And in the end, I succeeded.\n\nOne of my first attempts was trying to port the excellent [sqitch](https://sqitch.org/) database management tool from Perl to Python. I was already writing extremely detailed prompts, so I broke the project down and wrote detailed specs for each step.\n\nIt was a disaster, but here’s where my experiment kicked in: I wouldn’t read the code until failure. When it failed, I’d try to figure out the root cause and figure out what I could do to address it. I did that and instantly realized my mistake when I saw classes doing horrendous things to reinvent functionality that the sqitch codebase already provided.\n\nThe problem is that if we think of a large codebase as a graph, the leaf nodes are those nodes which have no dependencies on anything *inside* the graph. Port those first, remove them from the graph, and you have a new set of leaf nodes to port (with the edge case of circular dependencies). So I decided to create this graph and port things in that order. It worked! I chose sqlite migration as my first target and after a lot of grief (LLMs were much weaker back then), I had fully working code. I could easily use database change migrations with SQLite!\n\nBut it’s in Python and that’s not my strength. So I reached out to Fosstodon (the FOSS Mastodon server) and asked:\n\nNote that I did *not* mention AI. That was deliberate. And I got [an amazing review](https://fosstodon.org/@ovid/115365657494405806) from none other than [Glyph](https://en.wikipedia.org/wiki/Glyph_Lefkowitz), the author of Python’s Twisted framework (thank you, Glyph!). He pointed out tons of little problems, all of which stem from one source: I don’t know Python. However, he finished with [“this looks good”](https://fosstodon.org/@glyph@mastodon.social/115365806170480900).\n\nAh ha! Lessons learned:\n\nNow that I had SQLite working, I fixed the issues that Glyph identified and moved on to PostgreSQL, excited as hell that I was on the right track.\n\nPostgreSQL crashed and burned. It turns out that because I focused on the SQLite port, the AI had embedded assumptions about SQLite all throughout the code. I decided it would take longer to “fix” the code than to start from scratch, so I moved on, but kept the lessons learned.\n\nI’ll skip most of the rest of the journey, but my process became this:\n\nOver time, I built up useful set skills and after enjoying [the amazing Superpowers](https://github.com/obra/superpowers/), I realized I needed to organize my skills into a plugin. This is the birth of [PAAD, which provides defense-in-depth for AI-assisted programming](https://github.com/Ovid/paad). The process is roughly:\n\nAll of that probably looks like what you’re doing *without* AI. There’s a reason for this that we’ll cover in a bit.\n\nI originally created the plugin for Claude Code, but [you can easily install it on over 70 different agentic coding tools](https://github.com/Ovid/paad#quick-start). To get people up to speed, [I’ve published a free course on writing production-quality code with AI](https://curtispoe.org/paad/) (no ads, no registration).\n\nWait! Did I just promise an article on writing production-quality code with AI and then just point you to my web site? Well, yeah. Trust me, by the time you’re done working through that free course, you’ll understand that I couldn’t just publish a single article here (and I don’t have the time to convert it into a series).\n\nMany of you have seen AI in action and you're disappointed. The first day seems magical. The first month is productive. And after a while, you realize that you have god objects, global mutable state, numerous security holes, and a mess of a codebase that's going to take forever to untangle.\n\nThat's because AI focuses on the task you gave it and works hard to solve that task. It doesn't naturally look at the big picture. At best, it's a junior developer. When bad patterns creep into the codebase, the prediction machine uses those bad patterns to help make new predictions. Flaws in your codebase encourage the AI to compound those flaws.\n\nThe truth is simple: people may be amazing senior developers, but when they start with AI, they’re *junior* AI developers. AI is often treated as magic pixie dust you can sprinkle on a problem and hope the problem goes away. This is also known as “prompt and pray.” I call it AI-led engineering and in the long run, it doesn’t work (I’m hopeful that will change in the future).\n\nI don't teach AI-led engineering. I teach **engineering-led AI**. Over the course of building out these skills, I was constantly reading about new tips and technologies, but most of them ignore the central problem: AI can do tasks, but it can’t do jobs. AI solves the problem you have *now*, but it doesn’t automatically think about the big picture. On top of that, it’s stochastic.\n\nWhat’s “stochastic”? It sort of means “predictable randomness” that produces something shaped like what you want, but has wild swings of behavior. That’s one of the big problems with AI.\n\nYou know what else is stochastic? Humans. That’s one of the big problems with humans. So how do I address this? I'm a good developer, but I still write tests. I ask for code review. I want CI/CD to catch things we may have missed. QA might catch even more. UAT and usability testing also help. And your overworked incident response teams are there to clean up the mess when your *multiple levels of defense-in-depth fail*.\n\nWhy don’t we have this defense-in-depth for AI? When I say that much of AI slop is just technical debt accumulating at AI speed, we know how to manage technical debt, so we know how to manage AI slop. That’s what PAAD provides. I’ve been writing software for decades and, to my surprise, I realized that PAAD is just an encoding of well-known *best practices* for software projects, but rewritten to function at the speed of AI.\n\nThere's nothing magical about PAAD. Instead of hoping that AI will do the work for us, we do the work, but let AI speed it up. Today, I often use PAAD to let my agentic harness write software in the background, while I'm in meetings, writing presentations, researching problems, etc. PAAD has given me a level of *safe* productivity I didn't have prior to AI.\n\nBut PAAD doesn’t work without engineering discipline. That’s why your expertise is still critical.\n\nGenerally speaking, when I teach how to write production-quality software with AI, the responses tends to fall into one of two camps:\n\nThe first response is because many teams are under pressure to deliver and often don't have the time to write brilliant code, or to fix the issues in their current codebase. PAAD gives them that time.\n\nThe second response isn’t common, but it tends to come from teams of extremely experienced engineers who excel at their craft and are given the time to maintain their codebase. They can write better software than PAAD can. So I remind them of Fortran.\n\nWhen IBM released Fortran in the 1950s, they had a problem. Developers could write code much faster with Fortran, but the resulting assembly code didn’t run quite as fast as what developers could write by hand. So developers complained. Management saw something different.\n\nDevelopers using Fortran could produce more working code. If it was OK to have programs that ran a bit slower, the economics of saving a huge amount of developer time won.\n\nIt was decades before compiler output could reliably outperform what humans could do. Today, only a handful of developers can write assembly that reliably outperforms what compilers can produce.\n\nI view PAAD as the Fortran of AI. Yes, you can write better code and you can sometimes write it faster than with PAAD. However, can you do that on more than three projects/branches at the same time? Probably not. (I can’t reliably do more than three simultaneously when I'm using PAAD).\n\nIf you want to see an early result of PAAD, you can play my game, [Tramp Freighter Blues](https://curtispoe.org/paad/tramp-freighter/). You can also check out [the GitHub repo](https://github.com/Ovid/tramp-freighter). It's almost 100K lines of code (counting tests). You own a small cargo ship, moving goods from star to star. You just want to retire, but you're in debt to a loan shark, your ship keeps breaking down, and then there's that rumor you keep hearing ...\n\nThe screenshot doesn't do the game justice. Apparently, dev.to resizes them and the image loses a lot of detail.\n\nOne reviewer asked why the game wasn't responsive and when I replied \"because I want people to see it on a large screen,\" they said my AI coding skills must not be very good if I can't make it responsive. The next day, I released a responsive version.\n\nThe game is complete but it’s not perfect. I finished it months ago and today, I’m pretty sure I can do better, but you can review the code for yourself. I’m not asking if the code is perfect (it’s not). I’m asking if it’s something you could maintain. I deliberately left it in its current state so you could see for yourself what PAAD produces. [If you find PAAD useful, please consider giving it a star](https://github.com/Ovid/paad).\n\nExperienced devs will look at what I've done and point out that this was all on greenfield (new) codebases. Even if the claims are true, they don't generalize to brownfield (legacy).\n\nI worried about the same thing. Does PAAD work with legacy codebases? Have I built a niche tool that doesn't generalize?\n\nThen I realized (again) that I was being silly. AI-generated code is still code. Prior to AI, much of my work was going in and rescuing legacy codebases and the process was largely the same.\n\n`/pushback` on your steering files (`CLAUDE.md`, `AGENTS.md`, or whatever your agentic harness uses) to make sure you understand the codebase`/test-roadmap` skill)`/agentic-architecture` + `/fix-architecture`)\nIt's honestly that easy. There's nothing magical about AI-generated code simply because AI was involved in writing it. Code is code. The engineering skills that you've developed over years are still in demand, but we use AI to augment those skills, not replace them.\n\n**Warning**: be very careful with the `/test-roadmap` skill. It makes it easy to build out a full test suite for your codebase. Like many of the skills, it generates AI artifacts (markdown documents) for you to review. However, I've discovered that it has an interesting habit of surfacing zero-day exploits. **Do not commit these.**\n\nPAAD is still relatively new, but it's growing.\n\nMultiple teams I've trained across Europe are now using PAAD. Later, it was adopted by a company in Switzerland who set me my first PR: Kiro and Antigravity integration.\n\nAn insurance company in the US trialed PAAD and reported that the `/pushback` skill revealed that their entire requirements process was broken. They were happy.\n\nCompanies in Cambridge and Lancashire have been providing me with feedback and some of this is led to the current work on PAAD V2.\n\nThat's not an exhaustive list. As of this writing, PAAD is at 110 stars on GitHub, so I assume other companies and individual developers are enjoying it.\n\nPAAD, of course, is still a new project. I would love your feedback after trying it.\n\nIf you're skeptical about PAAD (a healthy attitude!), try this: install it and run `/pushback` on your steering files (`CLAUDE.md`, `AGENTS.md`, `.kiro/steering/*.md`, `.cursor/rules`, or whatever your tools use). Let it walk you through what it finds. Then, whenever you generate any artifact with AI (especially specs!), run `/pushback` on it. This skill alone sells many of the devs who use PAAD.\n\nWhy run `pushback` on steering? If you have a bad ticket, you'll have some bad code. If you have a bad spec, you'll have lots of bad code. However, even if all of your specs and tickets are *perfect*, **a bad steering file will impact everything**. The higher up the stack a flaw lives, the more the damage spreads.\n\nAlso, note that many AI tools/workflows are designed to make AI produce *better* code. PAAD doesn't replace those tools; it assumes that that code will still have flaws and it will hunt them down mercilessly. Do you like Superpowers? Use it! Ponytail? Use it! Spec Kit? Use it! PAAD works just fine with other tools because it occupies a different space. \n\nThere's more more I could say, but this seems like a good place to stop. For more background, here are some references:\n\nNote that the tutorial doesn't really replace training. No matter how careful I am with it, the tutorial can't answer your questions. It can't mentor you. It can't be sure that you understood. However, with practice, and sometimes rereading the material, you should get the hang of it.\n\nI also do AI strategy, governance, responsible AI, and training. If you'd like to more posts on these topics, such as why your company's AI strategy isn't generating value, or if you have questions about PAAD in general, let me know in the comments.", "url": "https://wpnews.pro/news/writing-production-quality-code-with-ai", "canonical_source": "https://dev.to/ovid/writing-production-quality-code-with-ai-2f5c", "published_at": "2026-09-07 06:03:10+00:00", "updated_at": "2026-09-07 06:27:14.317888+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools", "ai-products"], "entities": ["Curtis Poe", "PAAD", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/writing-production-quality-code-with-ai", "markdown": "https://wpnews.pro/news/writing-production-quality-code-with-ai.md", "text": "https://wpnews.pro/news/writing-production-quality-code-with-ai.txt", "jsonld": "https://wpnews.pro/news/writing-production-quality-code-with-ai.jsonld"}}