I went to a developer conference to learn from the pros. I left with a longer list of things to learn, a few new tricks for my AI tools, and more confidence that vibe coders belong in the room.
I spent Saturday at the Atlanta Developers' Conference (ATL DevCon) in Alpharetta. It's a community-focused event that brings developers, architects, and technology professionals together to share what they're building, what they've learned, and what actually works.
When we announced our first community partnership with ATL DevCon, I encouraged GRC practitioners not to let the word developer scare them away. After spending a day at the conference, I feel even more strongly about that advice.
The conference organizers also put on the Atlanta Cloud + AI Conference in the spring. I'll definitely be keeping an eye out for Spring 2027 too, with the date still to be announced.
What impressed me most wasn't just the technical content. It was how welcoming and approachable the sessions were. I attended five talks covering AI-assisted development, software architecture, testing, and security. The speakers were knowledgeable, but they were also willing to explain things in ways that made the material accessible.
I know because I tested that pretty early.
Wait, What's an ADR?
During my first session, Chad Green's Architecting with AI: From Requirements to Reality, I raised my hand to ask what an ADR was.
An Architecture Decision Record (ADR) is a short document explaining an important technical decision, why it was made, and what alternatives were considered.
It's the kind of term experienced developers can casually drop into a conversation while the rest of us are trying to keep up.
And that's exactly why I asked.
I've been building websites, experimenting with AI coding agents, and working on the GRC Vibe Coder's Playbook for the Atlanta chapter of the GRC Engineering Club. I've also spent a lot of time thinking about planning, documenting decisions, and making projects easier for another AI agent to pick up.
So the concept wasn't entirely new to me. I just didn't know the name.
That was one of my favorite moments of the conference. Nobody made it uncomfortable to ask. I got an answer, learned something useful, and kept going.
Planning Like an Engineer
We've emphasized planning several times in the Playbook. Define what you're building, understand the requirements, give your AI tools useful context, and don't jump straight into generating code.
Chad Green's session took that advice to another level.
He talked about using AI to clarify ambiguous requirements, explore multiple architecture options, compare tradeoffs, and challenge assumptions. One suggestion was to use another AI model to deliberately disagree with your proposed design and look for blind spots.
I loved that.
One of the risks of vibe coding is how quickly an AI can turn your first idea into something that looks finished. But the first idea isn't always the best one, and the first interpretation of a requirement isn't always correct.
The session also reinforced something I've been learning firsthand: templates alone aren't enough.
Give an AI tool instructions, a template, and examples of what good work looks like. Those examples help it understand the result you're actually trying to achieve.
And when you make an important design decision, record it. An ADR is one way to make that decision understandable to your future self, your teammates, and the next AI agent working on the project.
The Code Is the Easy Part
Ryan Edge's Lessons Learned Building with AI: From Zero Trust to High Confidence delivered another lesson that stuck with me: don't confuse confidence with assurance.
AI can generate code that looks reasonable, tests that pass, and documentation that sounds convincing. None of those things automatically proves the implementation is correct.
Ryan shared examples of AI choosing quick solutions, producing inconsistent patterns, and struggling with design handoffs. His advice included starting with low-risk tasks, giving agents explicit behavioral rules, and approving specifications before implementation.
I particularly liked the idea of using examples of correct and incorrect behavior to establish expectations, along with clearer acceptance criteria.
That's something anyone can try, regardless of how much code they understand.
Instead of telling your AI tool to write better code, show it a pattern you want followed. Instead of vaguely asking it to test an application, explain the behavior the tests should verify.
Better instructions don't eliminate mistakes, but they make the work easier to review.
Learning the Whole Lifecycle
The session Vibe Coding for Pro Developers: From Hype to Full Lifecycle Engineering might have been the clearest confirmation of what I've been thinking about lately.
Vibe coding isn't just prompting an AI to build something and hoping it works.
The speaker walked through a development lifecycle that included testing risky assumptions, planning architecture, building and testing, security hardening, operating software, and managing future changes.
A few ideas stood out.
Start with a cheap prototype that tests your biggest assumption. Write down your intent before generating code. When you discover a bug, create a test that demonstrates the problem before fixing it. Make security and operations explicit parts of the process instead of treating them as cleanup work.
The discussion also covered infrastructure as code, software dependencies, identity, and deployment.
I don't expect every new vibe coder to understand all of those subjects immediately. I'm still learning plenty of them myself.
But I do think we should aspire to understand more of the software development lifecycle (SDLC) as our projects become more ambitious.
You can start by building a simple website. Then learn how to use GitHub, review a pull request, write a test, understand an architecture decision, or check a dependency for vulnerabilities.
Each new skill gives you another way to improve your builds and avoid mistakes.
Governance Is Part of Building
My final two sessions brought the day even closer to my GRC background.
Karan Nisar's Ship the Agent, Prove It Was Safe focused on questions every team releasing AI systems should be able to answer: What was tested? Which version was tested? Who approved it? What evidence supported that approval?
Ashima Chakravarty's Shipping AI-Generated Code Safely explored independent testing, security reviews, provenance, accountability, and the ability to roll back changes.
Those questions should sound familiar to GRC practitioners.
The difference is that developers are applying them directly to how software gets built and released.
That's where I see a tremendous opportunity for GRC engineering. We can learn development practices while bringing our experience with risk, controls, evidence, and accountability into the process.
There's Room for Every Level of Vibe Coder
We've been exploring four levels of vibe coding in our learning program: Explorer, Builder, Coordinator, and Engineer. Some people are just discovering that they can build useful software with AI. Others are learning to manage repositories, review code, work with multiple agents, and understand increasingly complex systems.
The levels describe working habits you can develop, not credentials or a ranking of your GRC expertise.
The goal isn't for everyone to reach the same destination.
It's to keep learning enough to take greater ownership of what we're building.
Saturday gave me several small ways to level up. I can spend more time evaluating architecture options before implementation, give my agents stronger examples, test assumptions earlier, and improve the evidence I collect before approving changes.
And I'm encouraged that experienced developers are wrestling with many of the same challenges.
I went to ATL DevCon expecting to learn technical skills. I left feeling even more strongly that vibe coding has a place in the development community.
We shouldn't pretend that generating software makes us experienced engineers overnight. But we shouldn't let unfamiliar terminology or the fear of asking basic questions keep us from participating, either.
Build something. Learn how it works. Ask the question. Improve the next version.
That's how we get better, and it's how we become part of the community.
Thank you to the ATL DevCon organizers for welcoming our GRC Engineering chapter. We enjoyed being part of the event and hope to continue supporting the developer community as a community partner at future conferences.