A few months ago, I was handed a problem to solve. Business logic for selecting the right workflow was buried in deeply nested if-else chains across multiple services. Dozens of conditions, multiple dimensions, all defined in spreadsheets. Every time a rule changed, it meant code changes, code review, deployment, and prayer.
Good luck figuring out what the rules actually were. Nobody could test them without deploying. And you could hardly trace a code change back to the business intent behind it.
I wanted to fix this. Not with a document and a long roadmap. I wanted to build something working. So I sat down with an AI assistant and started.
What I Actually Built
A rule engine with a visual editor. Business rules as flowcharts. Testable without deploying. Versioned like code.
25k+ lines of code. 40% of that was tests. 6 documentation guides. 26 sample rule definitions. A working demo.
Twelve days. And plenty of wrong turns along the way.
What AI Can't Do
I want to get this out of the way early, because the "12 days" number is misleading without context.
AI can't tell you what to build. It can't evaluate whether your architecture will hold up under real traffic. It can't make the judgment call to push back on a requirement that doesn't make sense. It doesn't understand your business.
I caught the AI generating code that looked correct but violated a constraint I hadn't explicitly stated. It happened more than once. If I'd blindly accepted the output, I would've shipped bugs that were harder to find than the ones I was trying to prevent.
The twelve days were possible because I already knew the domain. I understood the problem. I had opinions about how to solve it. AI didn't give me any of that.
The Workflow That Made It Possible
I didn't just open ChatGPT and say "build me a rule engine." That doesn't work. What worked was treating AI as a pair programmer with a very specific loop.
Before writing any code, I configured the AI. Set up a system prompt with project conventions, coding guidelines, and constraints. Chose the stack and architecture. Think of it as onboarding your pair programmer. I kept tweaking these as the project evolved.
Every feature followed four steps:
Design first. I'd write a markdown spec before any code. "The engine evaluates rules in isolation. No DB calls, no side effects." Then I'd discuss edge cases with the AI until the spec was solid. No code until we agreed on the design.
Implement from the spec. The AI would generate code based on the spec. I'd review every line. Not skim it. Read it. Then I'd ask the AI to write tests and validation for what it just built. And I'd review those tests too. A test you don't understand is worse than no test at all.
Feedback loop. Fix errors. Run the tests, read the failures, make sure they're testing what matters. Update docs when the implementation diverged from the spec. Validate against the original requirements. Keep tests green.
Deploy and move on. Build locally, smoke test, validate end-to-end. Then start the next feature.
This loop is the discipline. Skip any step and the whole thing falls apart.
What I Brought vs. What AI Brought
This is the part people get wrong. They think AI did the work. It didn't. So what did I actually do?
I brought the problem. I knew why the current system was broken. I knew what the business needed. I made every architecture decision. I picked the backend language based on performance requirements. I chose to embed a scripting runtime for rule evaluation. I designed the caching layer that turned 5-50ms evaluations into sub-microsecond lookups.
And I needed to know enough about config files, containers, infrastructure, backend, and frontend code to validate what the AI produced and make real decisions. You can't review code you don't understand.
AI brought speed. It scaffolded the storage layer from a markdown spec in one session. It generated tests that caught edge cases I would've missed under time pressure, like circular rule references and empty decision tables. It switched between backend, frontend, containers, and infrastructure config without blinking.
The combination is what made twelve days possible. Not AI alone.
Where I Actually Spent My Time
The biggest win wasn't writing code faster. It was where my attention went. Ever notice how much of your day is spent on stuff that isn't the actual problem?
I stopped thinking about boilerplate, wiring, and syntax. My entire focus shifted to what to build and why. Design decisions. User experience. Architecture trade-offs. The stuff that was always the real job anyway.
And because I asked AI to generate tests alongside every feature, I could iterate aggressively without fear. Change the caching strategy? Tests catch regressions. Refactor the rule evaluation pipeline? Tests tell me if I broke something. That safety net is what let me move fast without moving recklessly. How often do you skip tests because you're "pretty sure" it works?
Docs happened too. Not because I'm disciplined. Because I was writing specs for the AI anyway, so the docs were a side effect of the workflow. Six guides shipped. Zero skipped.
The Uncomfortable Truth
Here's what I keep coming back to. AI is making the gap between developers who know their stuff and developers who don't wider than it's ever been.
If you understand how things work, you can direct the AI, catch its mistakes, and make decisions it can't make. You get a real multiplier. If you don't, you're pasting code you can't evaluate into a system you can't debug. That works until it doesn't. And when it breaks, you're stuck.
I couldn't have built this in twelve days if I didn't already understand concurrency, how runtimes work, what makes a good API, or how container layers affect build times. The AI didn't teach me any of that. Years of actually learning those things did.
So if you're wondering whether it's still worth investing time in actually learning JavaScript, TypeScript, or how your framework works under the hood, the answer is yes. That knowledge is what turns AI from a toy into a tool.
Key Takeaways
- AI is a pair programmer, not an autopilot. You bring the problem and the judgment. It brings the speed.
- Spec first, code second. Write a markdown doc before generating any code. Discuss trade-offs. No code until the design is solid.
- Tests aren't optional anymore. When AI writes your code, tests are how you verify it works. Write them alongside every feature. Review them like you'd review the code itself.
- Docs are a side effect of good workflow. If you're writing specs for AI, you're already writing docs.
- The fundamentals are the multiplier. AI amplifies what you know. If you don't know much, it amplifies that too.