Schemas as application code means you get version control, PR review and type‑safe changes.
A query builder that feels like SQL and lets you write “real” ClickHouse queries with IDE autocompletion and compile‑time checking.
Local development and CI should mirror production so you can preview schema changes before they apply to prod.
>>>
I believe this is what dbt set out to accomplish. They came at the problem from the point of view of a data transformation language that is essentially a pseudo type checked SQL for analytical engines with some additional batteries included (ie macros) but the motivation was similar. I’ve always felt that what has held dbt back from more mainstream adoption by the dev community is because they’ve prioritized data transformation over data access to the application layer - ie business intelligence tools over a web app.
Moosestack looks interesting- will definitely check it out.
I’m at this stage where I’m fine with AI generated content. Sure, the verbosity sucks - but there’s an interesting idea here, but make it clear that you’ve used AI, and show your prompts.
this isn’t vibe coding. This is something completely new. I call it “flex coding.”
heck I built a full app in an afternoon AND I was a good dad?
> I'd wander into my office, check what Claude had built, test it real quick. If it worked, great! Commit and push. "Now build the server connection UI," I'd say, and wander back out.
Made breakfast. Claude coded.
Played with my son. Claude coded.
Watched some TV. Claude coded.
Every hour or so, I'd pop back in. Five minutes of testing. One minute of feedback.
This is all very emotive and I'm sure is a dream many of us would love to live.
But does Claude's code work? Does it work to the level where you'd depend on it yourself; where you'd bill customers for it; where you'd put your reputation behind it?
I say no. And it's because I use Claude. Two events changed how I use Claude: now it's an advisor, and I mostly type the code myself. Because I don't trust it.
First, I caught it copying one of my TypeScript interfaces and modifying it. So now we have User which looks like my actual user, that I defined, and UserAgain which does not, and which Claude is now using and proudly proclaiming that my type checks all pass. Well of course they do!
Second, I was told that the best way to catch this sort of thing is to get it to write tests. So it wrote some tests, and they failed, and it kept going, and it eventually wrote an un-failable test. The test mocked itself.
So, sure, enjoy time with your kids. Please don't ask me to use your app for anything important.
It's interesting reading comments on both sides of this. Some people are answering no, and others are answering yes to your question and succeeding at it... so far.
I've experienced the exact issues you've described. I've also drastically reduced these issues via good instructions and automated followup passes that eliminate code that was created from ignored instructions.
It all feels like a hack, but the more I choose to trust it and treat it like it's the correct path and that it's just a different set of problems that need to be solved, the more success I have.
I feel that it is a commom thing. You just have to "keep an eye on it". There are several failure modes with Claude. Maybe the most annoying is that it often uses kind of defensive programming, so it is harder to detect that there is a fatal mistake somewhere. It can hide those really well. And it loves to fix linter issues with any type in typescript.
Im using it regardless. Ive just learnt to deal with these and keep an eye on them. When it creates a duplicate interface I roll back to earlier prompt and be more explicit that this type already exists.
I try to not argue whether something it does is wrong or right. There is not point. I will simply rollback and try with another prompt. Claude is not a human.
I had Claude, as an agent, get into an infinite loop trying to resolve a diagnostic in Java test that any human would easily figured out and fixed in a second.
Because you can't do this yourself. You don't have the decades of experience to know how to ask the questions and when to steer the tool into a different direction.
Why not? As the AI people say "you can just do things". If there is little consequence to getting it wrong as a parent poster puts it why not? You can learn over time like any other skill.
I want to be wrong (it will affect me and my family personally) - but there is a reason every AI proponent talks about coding and making "coding redundant". For most jobs/industries software is a compliment (e.g. Product Owner, BA, etc) unless that is your main skill in which case it is your main service you are selling. Most roles want to turn software into a commodity or the typical business PM word "resource" that they can acquire as they need - the dream of most business roles (e.g. Project Managers, BA's, etc). It sadly also seems to be low hanging fruit of LLM's; doesn't mean there isn't other aspects to the job of course but coding is becoming "less special" with these technologies especially with common tech and use cases.
That's the real question IMO. Especially when everything that isn't deflationary with AI for the most part is getting much more expensive due to inflation globally. Save money on software, buy more blue collar goods.
If its an easy skill to learn, with little consequences if you get it wrong especially for small scale apps why pay for it? Don't know why seniors (of which I'm one) think they are immune to this.
consider it like this: you are not paying the amount of worked hours but for the expertise to judge, coach and guide the AI and its output according to your wishes. so if the result is good and within time and budget, why would you care?
And also how “internal” business intelligence/operations tools should work. search first to find relevant artifacts - “top 10 customers in AMEA”, followed by agentic verification and enrichment.
“… you can find frameworks not just in software, but also in ordinary life. If you buy package holidays, you're buying a framework - they transport you to some place, put you in a hotel, feed you and your activities have to fit into the shape provided by the framework (say, go into the pool and swim there). If you travel independently, you are composing libraries. You have to book your flights, find your accommodation and arrange your program (all using different libraries). It is more work, but you are in control - and you can arrange things exactly the way you need.”
My favorite blog post / presentation is Sandi Metz "The Wrong Abstraction", but this one is up there. Definitely punches above its weight for a small obscure post.
Hmm, that hit a bit of a nerve. My experience with switch blocks is it can be a gateway drug for teams A, B, C to add their special-case code to team D's repo within a `switch(calling_service)` block. My read of the presentation is more, factor your stuff so that any "switch" is a higher level concern that consumers can do in their own services. Then if you start to see all your consumers write very similar consumption logic, then start thinking about how to pull that down into the library/service itself.
13in MacBook Air (new M4, with 24GB RAM) and Mac Mini as desktop the best setup I’ve ever had. I debated between the 13in and 15inch MacBook Airs and am so glad I went with the 13.
A counterpoint, from someone who’s worked on SaaS billing /MRR reporting for 10+ years - it’s usually more complicated than just exposing an API endpoint for precalculated MRR by month. Most analysis requires drilling into dimensions of MRR growth - by cohort, by billing period, etc - and so while Stripe exposing an API for MRR could be helpful, it won’t cover most of the cases for proper financial analysis for a SaaS business. There’s also the complication of how MRR is computed across companies and domains - it’s not a GAAP metric and no standardized definitions.
Schemas as application code means you get version control, PR review and type‑safe changes. A query builder that feels like SQL and lets you write “real” ClickHouse queries with IDE autocompletion and compile‑time checking. Local development and CI should mirror production so you can preview schema changes before they apply to prod.
>>>
I believe this is what dbt set out to accomplish. They came at the problem from the point of view of a data transformation language that is essentially a pseudo type checked SQL for analytical engines with some additional batteries included (ie macros) but the motivation was similar. I’ve always felt that what has held dbt back from more mainstream adoption by the dev community is because they’ve prioritized data transformation over data access to the application layer - ie business intelligence tools over a web app.
Moosestack looks interesting- will definitely check it out.
reply