One Thing I Learned This Week: AI Code Generation Isnt About Writing Less Code

What Happened

I was working on a feature for Dokku UI – exporting application configurations to a portable format. Users should be able to download their app's environment variables, domains, and settings as a file they can import elsewhere.

My first instinct: "This should export to JSON."

Simple. Structured. Easy to parse.

I opened Cursor (my AI-powered editor) and started typing:

# Export app configuration to JSON
def export_configuration
  {
    app_name: name,
    env_vars: environment_variables.to_h,
    domains: domains.pluck(:name),
    # ...
  }.to_json
end

Then I paused.

What if JSON isn't the best format? What if users want to import this into a different tool? What if they want to read it as documentation?

Normally, this is where I'd stop. Implementing multiple export formats takes time. I'd ship JSON, plan to "add more formats later" (which never happens), and move on.

But with AI, I could explore in minutes instead of hours.

The Experiment

I asked Claude (via Cursor):

"Show me 5 different ways to export this configuration data, with pros and cons of each format for a DevOps use case"

30 seconds later, I had:

1. JSON

{
  "app_name": "myapp",
  "env_vars": {
    "DATABASE_URL": "postgres://..."
  },
  "domains": ["example.com"]
}

Pros: Universal, easy to parse Cons: Not human-readable, no comments

2. YAML

app_name: myapp
env_vars:
  DATABASE_URL: postgres://...
domains:
  - example.com

Pros: Human-readable, supports comments Cons: Whitespace-sensitive, can be ambiguous

3. .env format

# Application: myapp
DATABASE_URL=postgres://...
# Domains: example.com

Pros: Directly usable in many tools Cons: Limited structure, loses metadata

4. Terraform HCL

resource "dokku_app" "myapp" {
  name = "myapp"
  config = {
    DATABASE_URL = "postgres://..."
  }
  domains = ["example.com"]
}

Pros: Infrastructure-as-code ready Cons: Dokku-specific, requires Terraform knowledge

5. Shell script

#!/bin/bash
dokku apps:create myapp
dokku config:set myapp DATABASE_URL=postgres://...
dokku domains:add myapp example.com

Pros: Executable, self-documenting Cons: Platform-specific, harder to parse programmatically

The Realization

Looking at these options, I realized: The shell script format is brilliant for this use case.

Why?

• Users can literally run it to recreate the app
• It's self-documenting (you see the exact commands)
• It's portable (works on any Dokku server)
• It's readable (even non-technical team members can understand it)

I never would have considered this without AI.

My brain defaults to JSON because that's what APIs return. But this isn't an API response – it's a migration tool. The shell script format is perfect.

What Changed

I implemented shell script export:

def export_as_shell_script
  script = []
  script << "#!/bin/bash"
  script << "# Dokku application configuration export"
  script << "# Generated: #{Time.current}"
  script << ""
  script << "APP_NAME=#{name}"
  script << ""
  script << "# Create application"
  script << "dokku apps:create $APP_NAME"
  script << ""
  
  if environment_variables.any?
    script << "# Set environment variables"
    environment_variables.each do |key, value|
      # Escape for shell safety
      escaped_value = value.gsub("'", "'\\\\''")
      script << "dokku config:set $APP_NAME #{key}='#{escaped_value}'"
    end
    script << ""
  end
  
  if domains.any?
    script << "# Add domains"
    domains.each do |domain|
      script << "dokku domains:add $APP_NAME #{domain.name}"
    end
    script << ""
  end
  
  script << "echo 'Configuration import complete!'"
  script.join("\n")
end

Users love it.

They download the script, review it (security-conscious DevOps folks appreciate being able to read exactly what it does), modify it if needed, and run it.

One user told me: "This is so much better than JSON. I can see exactly what it's doing. I even use these exports as documentation for our deployment process."

I wouldn't have built this without AI helping me explore options.

The Broader Lesson

Here's what I learned: AI coding tools aren't about writing code faster – they're about exploring the solution space more thoroughly.

Before AI:

• Think of one solution
• Implement it
• Ship it
• Maybe reconsider later (probably not)

With AI:

• Think of one solution
• Ask AI for alternatives
• See 5 different approaches in seconds
• Choose the best one
• Implement it (often with AI help)
• Ship something better

The time saved isn't in the typing – it's in the exploration.

How This Changed My Workflow

Now when I'm implementing a feature, I do this:

1. Pause Before Implementing

Don't go with your first instinct. Ask: "What are the alternatives?"

2. Ask AI to Explore

Prompt examples I use:

• "Show me 3 different ways to implement [feature], with trade-offs"
• "What are alternatives to [my approach] for [use case]?"
• "How would you solve [problem] if [constraint]?"

3. Evaluate Options

AI gives you options. You choose. You're still the decision-maker.

4. Implement the Best Solution

Sometimes it's your original idea. Often it's a hybrid. Occasionally it's something you never considered.

What AI Is Actually Good For

Through this experience, I've realized AI coding tools excel at:

• Generating boilerplate Need a serializer? Controller scaffold? Test setup? AI writes it in seconds.
• Exploring alternatives "Show me different ways to..." is incredibly powerful.
• Explaining unfamiliar code Inherited legacy code? Ask AI to explain what it does.
• Refactoring suggestions "How would you refactor this?" often reveals better patterns.
• Writing tests AI is surprisingly good at generating test cases you might miss.

What AI Is Not Good For

But it has clear limitations:

• Architectural decisions AI doesn't know your business constraints, team skills, or long-term vision.
• Complex debugging AI can suggest fixes, but deep debugging requires human understanding.
• Performance optimization AI doesn't know your data volumes, traffic patterns, or bottlenecks.
• Security considerations AI might generate vulnerable code. You need to audit.
• Knowing what to build AI can't tell you what features users need. That's still your job.

The Meta-Lesson

The real insight isn't about AI at all.

It's about exploration.

Before AI, exploration was expensive. Trying different approaches meant writing different implementations, which took hours or days.

Now, exploration is cheap. You can see multiple approaches in minutes.

This changes the game.

It's like the difference between:

• Having one attempt at a difficult shot (better make it count)
• Having unlimited practice shots (try everything, learn what works)

AI gives you unlimited practice shots before you commit.

My New Rule

Never implement the first solution that comes to mind without asking AI for alternatives.

Not because AI is smarter – it's not.

But because seeing multiple approaches makes you smarter.

Even if you ultimately choose your original idea, you choose it with confidence because you've seen why it's better than the alternatives.

Try This Yourself

Next time you're about to implement something, pause and ask your AI tool:

"Show me 3-5 different ways to implement [what you're building], with pros and cons for each approach."

Then actually read the alternatives. Don't just skim them.

You might be surprised what you learn.

Final Thought

AI didn't make me a faster coder this week.

It made me a better decision-maker.

And in the long run, that's far more valuable.