Not affiliated with FlutterFlow, but I found the first few minutes of the video very compelling - especially when you put it in the context of AI chat interfaces and flow builders.
Is there ever a point where a 'code-native' developer prefers a low-code/no-code solution over writing it all out themselves?
This is cool. Reminds me of my internship days when I had to build a custom 8086 emulator in Java, and I went down the rabbit hole of trying to figure out the best way to represent the architecture.
While this isn't surprising considering how bad it was, it is surprising considering that they recently announced the whole Amazon Q for software development thing. Who's going to trust them with Dev tooling now?
Linters are great at finding syntactical errors like the case you mentioned. But LLMs do a better job at finding logical flaws or enforcing things like non-syntactic naming conventions. The idea is not to replace linters, but to complement them. In fact, one of the flows we're building next is fixing linting issues that linters struggle to fix automatically.
I agree and disagree. You definitely need someone competent to take a look before merging in code, but you can do a first pass with an LLM to provide immediate feedback on any obvious issues as defined in your internal engineering standards.
Especially helpful if you're a team with where there's a wide variance in competency/experience levels.
This is where prompting and context is key - you need to keep the scope of the review limited and well-defined. And ideally, you want to validate the review with another LLM before passing it to the dev.
Still won't be perfect, but you'll definitely get to a point where it's a net positive overall - especially with frontier models.
That happens with human review too and often serves as an opportunity to clarify your reasoning to both the reviewer and yourself. If the code is easily misunderstood then you should take a second look at it and do something to make it easier to understand. Sometimes that process even turns up a problem that isn’t a bug now but could become one later when the code is modified by someone in the future.
There are a few open source projects by the name and we were aware of https://github.com/ssbc/patchwork which is archived. Didn't know of this though.
It's a common noun which works really well for patch-based offerings I guess, and we chose it because we built a 'framework to patch code'. But we'll think more about this - thanks for bringing it up.
1. You use Aider to complete a novel task you're actively working on. Patchwork completes repetitive tasks passively without bothering you. For e.g. updating a function v/s fixing linting errors.
2. Aider is agentic, so it figures out how to do a task itself. This trades accuracy in favor of flexibility. With patchwork, you control exactly how the task is done by defining a patchflow. This limits the set of tasks to those that you have pre-defined but gives much higher accuracy for those tasks.
While the demo shows CLI use, the ideal use case patchwork is as part of your CI or even a serverless deployment triggered via event webhooks. Hope this helps? :)
