Kevin Hoffman expanded on that with the 15-factor app: <a href="https://developer.ibm.com/articles/15-factor-applications/" rel="nofollow">https://developer.ibm.com/articles/15-factor-applications/
Mind you I may be dating myself as I was first introduced to this paradigm in 2015 working as a Java SpringBoot engineer on an enterprise project that I then migrated (57 microservices) all to Scala, after onboarding two weeks to Scala fresh from no prior Java experience.
I feel like there is so much "wisdom" encoded in books and writings from some of the most prolific engineers and architects over the last several decades.
Look at Matt Pocock's skills with simple primitives like grilling the human, researching through wayfinder maps (a Godsend to my workflow prior to Cursor Projects and orchestrator patterns), and having a solid Domain Driven Design through defining a shared glossary and breaking up work around proper seams.
Could you share some higher bars that may make up a better "rubric" for this issue? I am actively trying to do so. Shy of just condensing core Manning publications that cover domains of interest, I am struggling to find a good bar to have my clankers validate against outside of minimizing cyclomatic complexity.
Cyclomatic (and cognitive complexity) are a good start.
Some other ideas
1) Enforce architecture decisions (see archunit). But somebody needs to write them down first.
2) Check that tests actually break if the code that accompanies them is removed (several LLMs/agents today create tests that don't actually test the code they "guard against)
3) Automated performance testing. An LLM/agent might create a change that is "correct" but increases latency for 3x (best case) and 20x (worst case)
The hardest part that I see no solution for today is to understand when a change breaks backwards compatibility. LLMs/agents are trigger-happy and will happily refactor/remove stuff without any care about who is using that.I don't have a proposal for that, but the problem is there and is not covered by 12-factor config.
Excellent set of criteria, thank you. Something like am archlint, or performance lint, and sanity check on tests "Actually testing a seam or function" of the actual code base sound like good research avenues.
tylerjharden · · focus · HN ↗
<a href="https://12factor.net/" rel="nofollow">https://12factor.net/ <a href="https://en.wikipedia.org/wiki/Twelve-Factor_App_methodology" rel="nofollow">https://en.wikipedia.org/wiki/Twelve-Factor_App_methodology
Kevin Hoffman expanded on that with the 15-factor app: <a href="https://developer.ibm.com/articles/15-factor-applications/" rel="nofollow">https://developer.ibm.com/articles/15-factor-applications/
Mind you I may be dating myself as I was first introduced to this paradigm in 2015 working as a Java SpringBoot engineer on an enterprise project that I then migrated (57 microservices) all to Scala, after onboarding two weeks to Scala fresh from no prior Java experience.
I feel like there is so much "wisdom" encoded in books and writings from some of the most prolific engineers and architects over the last several decades.
Look at Matt Pocock's skills with simple primitives like grilling the human, researching through wayfinder maps (a Godsend to my workflow prior to Cursor Projects and orchestrator patterns), and having a solid Domain Driven Design through defining a shared glossary and breaking up work around proper seams.
kkapelon · · focus · HN ↗
It is perfectly possible to vibe-code a badly designed app that still passes those 12, 15 or whatever points you define.
tylerjharden · · focus · HN ↗
kkapelon · · focus · HN ↗
Some other ideas
1) Enforce architecture decisions (see archunit). But somebody needs to write them down first.
2) Check that tests actually break if the code that accompanies them is removed (several LLMs/agents today create tests that don't actually test the code they "guard against)
3) Automated performance testing. An LLM/agent might create a change that is "correct" but increases latency for 3x (best case) and 20x (worst case)
The hardest part that I see no solution for today is to understand when a change breaks backwards compatibility. LLMs/agents are trigger-happy and will happily refactor/remove stuff without any care about who is using that.I don't have a proposal for that, but the problem is there and is not covered by 12-factor config.
tylerjharden · · focus · HN ↗