Using AI the Parthenon Way

Since absolutely nobody is talking about AI right now, this felt like a good time to write an AI article. Programmer opinion across the Internet ranges from enthusiastic acceptance to furious rejection, but in my opinion, both extremes have a lot to do with politics and personality, and very little to do with empirical experience – the tech is simply too new for people to have fully gotten their heads around it. So is AI really useful for software development? And if so, how do we use it?

From systems to databases to project design process, Parthenon’s always approached our projects holistically; you can’t make good custom software without knowing what parts work together best, and AI is no exception. As such, our AI is all local, built into our toolchain, running inside our office, and not sending anything to the outside world. Models we run are tuned and tested by us on internal projects before they’re used. And we use minimalistic tools that let us see and control the entire process; we don’t like “black boxes”. Many of our customers are sensitive to their intellectual property being used for AI training, and we share some of their concerns. As such, we don’t ever let customer code leave our office.

Now that we’ve used it for a while, I can definitely tell you it can be handy…if you know how to use it right. Agentic AI is a power tool that has little in common with the chatbots most non-programmers use; think about how carpenters used to work before power tools came into existence and you’ll get an idea of what the software industry has been like in the past compared to what we’re starting to see. Some things that were really tedious just got a lot easier, and even though some types of tasks will probably disappear, many other opportunities that used not to be cost-effective are opening up.

But as with most advances in software development, the details really matter. Because an AI can do so much in so little time, it needs its own best practices. We’ve evolved some good guidelines on what works best for us to do with an agent versus what’s better to code up by hand, They’re not going to be set in stone, though – the field is still changing faster than anyone can keep up.

One thing that hasn’t changed is our need to know what we’re writing. I always tell my junior devs and interns that it’s better to have the code in your head than in a book or knowledge base, and it’s better still to have it in your hands than in your head. A big mistake a lot of shops make is to ask for major changes from an AI agent, receive a giant pile of code, and then get put in the position of either uncritically accepting it or throwing the results away. If we’re throwing an agent at a task, it’s a focused one so we can evaluate the quality and steer the agent.

We’ve also found that we get far better results from AI prompts if we can provide proper background information without getting too deep into the weeds, and having the model attempt to explain its strategy before starting. Tooling (the skills files, MCPs, or local extensions to our agents that we use) is almost more important than the model itself! Not only does the tooling and strategizing give us a better idea of the strategy we’re about to take for a task, the extra context we provide it vastly increases the accuracy of the code the system produces, making our code reviews faster and easier.

We’re entering an era where a lot more code can be written a lot faster, with a lot less initial knowledge. But the roots of our craft remain the same, even if we just got a new set of power tools.