Skip to content
Notifications
Clear all

My results after a 48-hour hackathon using only Le Chat for prototyping.

9 Posts
9 Users
0 Reactions
2 Views
(@cloud_infra_newbie)
Reputable Member
Joined: 4 months ago
Posts: 177
Topic starter   [#20980]

Hey everyone! I just tried using Le Chat (the free tier) as my sole assistant during a weekend hackathon. The goal was to build a simple serverless URL shortener on AWS. No human help, just the AI.

My main takeaway: it's amazing for boilerplate and explaining concepts, but you have to be very specific with Terraform. For example, I asked for a Lambda function with an API Gateway trigger. It gave me this:

```hcl
resource "aws_lambda_function" "url_shortener" {
filename = "function.zip"
function_name = "url_shortener"
role = aws_iam_role.lambda_exec.arn
handler = "index.handler"
runtime = "nodejs18.x"
}
```

But I kept getting errors because it didn't auto-generate the IAM role dependencies. I had to explicitly ask: "Now give me the IAM role for that Lambda with assume role policy." Then it worked.

It was super fast for writing the actual Lambda code (Node.js) and explaining how to set up DynamoDB. However, when I asked about configuring CORS for the API Gateway, the solution it provided didn't work at first. I had to iterate a few times.

Overall, it felt like pair programming with a very patient senior who sometimes misses the obvious next step 😅. For a newbie like me, it forced me to understand each piece because I had to ask for them one by one.

Would I use it again for a time-limited prototype? Absolutely. But I'd probably have the AWS/Terraform docs open alongside to fill in the gaps it sometimes leaves.



   
Quote
(@consultant_carl_42)
Estimable Member
Joined: 2 months ago
Posts: 127
 

Ah, the classic "pair programming with a very patient senior who sometimes misses the obvious next step." That's a generous way to frame it. What you've actually described is a tool that's fantastic at generating the lines of code it's seen a million times before, and utterly lost when the problem requires any degree of holistic system thinking.

You've hit the core of it: "you have to be very specific." That's the entire cost. The moment you stop being a flawless technical specification writer, the house of cards collapses. It's a fantastic parrot for boilerplate, but ask it to connect two pieces it hasn't seen joined in its training data, like that IAM role dependency, and it leaves you hanging.

I've watched teams burn weeks trying to "migrate" using this kind of piecemeal, chat-driven assembly. You get 90% of the way there in an afternoon, and spend the next two weeks in debugging hell because the AI never considered API throttling, concurrency limits, or what happens when your DynamoDB partition key design hits scale. It gives you the happy-path tutorial code, not the resilient system.

So, great for a hackathon. Terrifying as a blueprint for actual engineering.


Test the migration.


   
ReplyQuote
(@contrarian_kevin)
Estimable Member
Joined: 1 week ago
Posts: 123
 

Exactly. It's not missing the "obvious next step." It's missing the concept of "steps" altogether. It has no model of a system, just statistically likely tokens.

So sure, you'll get the IAM role after another prompt. Then you're three prompts deep chasing the next missing link, like the trust policy. You're not engineering, you're playing a very expensive game of whack-a-mole with your own spec.


Just saying.


   
ReplyQuote
(@datadog_dave_3)
Estimable Member
Joined: 3 months ago
Posts: 106
 

You've described a fundamental limitation, but I'd frame it as a difference between declarative and interactive specification. When I use an AI for Terraform, I'm essentially writing a spec in natural language. The "whack-a-mole" effect happens because my initial spec was incomplete, not because the tool failed.

It's similar to the difference between writing a detailed design doc up front versus sketching a high-level diagram and iterating. For experienced engineers who already know the required components, the iterative chat approach can be faster than searching documentation for exact HCL syntax. The problem arises when someone lacks the foundational knowledge to know what to ask for next.


null


   
ReplyQuote
(@crm_pragmatist)
Estimable Member
Joined: 2 months ago
Posts: 98
 

You're calling it a patient senior engineer, but a senior engineer would have anticipated the IAM role. That's the core oversight.

What you actually had was a very fast intern who's memorized a million code snippets but can't see the connections between them. The speed feels great until you hit that first missing dependency, then you're in prompt loop purgatory.

I've seen this exact pattern blow up real migrations. Someone gets excited because the AI spits out perfect Apex triggers, but then you realize it never generated the test classes to meet deployment coverage. You're just chasing the next error message.



   
ReplyQuote
(@calebs)
Eminent Member
Joined: 4 days ago
Posts: 24
 

Your example with the IAM role is exactly why it's dangerous to think of this as a "senior engineer." A senior engineer thinks in systems. An LLM thinks in tokens.

You're not getting incomplete answers because you're bad at prompting. You're getting incomplete answers because the tool has no internal model of the dependencies. It gave you the Lambda block because that's a common token sequence. The IAM role is a separate, also common token sequence. It doesn't know one requires the other. You'll hit this wall with any non-trivial infra.

It's a syntax generator, not an architect.



   
ReplyQuote
(@danielh)
Estimable Member
Joined: 1 week ago
Posts: 69
 

Totally feel the "debugging hell" scenario. That's the hidden tax on AI-assisted velocity.

What's been working for me is using it as a supercharged linter or pattern matcher, but never the architect. I'll sketch the whole system in a diagram first, then feed it one discrete component at a time. Like, "Here's my IAM role resource, now write the trust policy for a Lambda service principal."

It's not thinking in systems, you're right. But if you hold the system model in your own head and use it to fill in the syntax gaps, it can still save a ton of time.

The terrifying part is when people skip that "model in your own head" step. That's how you end up with three Lambdas and no VPC configuration.


Keep deploying!


   
ReplyQuote
(@darrenk)
Estimable Member
Joined: 1 week ago
Posts: 103
 

Nice! That's a great real-world test. Your "patient senior" analogy is spot on for the vibe.

The CORS thing is a perfect example of where it stumbles. It'll give you a textbook answer, but sometimes the implementation specifics for a service like API Gateway need that extra iteration. It's fast, but you still need to know enough to debug its output.


dk


   
ReplyQuote
(@billyp)
Estimable Member
Joined: 1 week ago
Posts: 59
 

Your hackathon test mirrors what I've seen using AI for marketing automation configs. It's brilliant at spitting out a perfect Klaviyo flow JSON snippet, but will it remember to add the mandatory "delay" node before the split? Nope, you'll get the error and have to ask.

Like your IAM role, it's a pattern completer, not a workflow thinker. For something as interconnected as a campaign or Terraform stack, you still need the whole map in your head. The speed is real, but so is the debugging tax.


Always A/B test.


   
ReplyQuote