Something very similar I was experimenting with on, but had different results that you may be interested in, some of my findings were interesting
This was part of testing out how well a tool of mine worked (github.com/jsuppe/loom), which aims to be used to extracts requirements, specs, creates tests. At first I had no intention of using it for code generation but then tried it out with some early success. I tried splitting the work by using the tool with different frontier models, and then providing work to a local ollama instance running one of several models. Not all local models had the same outcome, not all coding languages had the same outcome. I also found in this experiment, when nailing down the coding tasks I wanted to set up positive and negative scenarios- which is where I found setting guardrails can sometimes backfire with inversion- this essentially elaborates on previous work by Khan 2025 (https://arxiv.org/abs/2510.22251); the most interesting finding to me was that if you give guardrails with a rationale, it reduces compliance and may cause the inversion
For coding tasks I found that the improvement was not only ability to use a lower cost model for these broken down tasks, but wall clock time was improved over using frontier model alone, with equivalent outcomes.
100% I found that you think you are smarter than the LLM and knowing what you want, but this is not the case. Give the LLM some leeway to come up with solution based on what you are looking to achieve- give requirements, but don't ask it to produce the solution that you would have because then the response is forced and it is lower quality.
Smart glasses featuring cameras, a control bracelet, and in-lens displays represent significant technological progress with particularly valuable applications for people with disabilities. The non screen version could be transformative for blind users, while the display equipped model offers great potential for the deaf community. However, there's a notable double standard in social acceptance: while these devices are welcomed when serving accessibility needs, they face resistance when used recreationally, reflecting society's discomfort with wearable recording technology in casual social settings.
Some years before CUDA there was a lot of hype when the first GPGPU papers published in 2003 which showed significantly increasing performance using parallel computation from consumer graphics cards. At the time, it looked like competing on general purpose computation was a solid strategy: multi-core CPU from intel was still years away, showing up in 2005; starting from 2000 the rate of increase of clock speeds started slumping. We saw Intel started releasing more variants of processors, but the clock speeds weren't advancing exponentially anymore. The new battle for core supremacy was on the horizon.
I must have missed the fake stories. I just saw the ones about a school bus sized metal structure hovering over the US sent by China, endangering people below it.
Which is why there should be no moderators besides each person having an equal vote. "But then people game the system." is always the answer, which is always the root cause of the problem: on the internet, everything is completely fair until someone, inevitably, games the system.
NVIDIA/CUDA acceleration for AI/ML are the gold standard, and when there is a ton of investment money coming in (especially when way more is coming in, much faster than usual) the safe bet is to stick with the standard. Additionally, they have the backing of NVIDIA which is huge and has ton of resources poured in to this, compared to any other competitor. On a risk adjusted basis, NVIDIA is a solid choice to standardize on and stick with.
A large part of software development is documentation. It is often overlooked or not kept up to date. I think the great advancement of AI is that we can now more closely link and validate one with the other. You can easily summarize some code with chatGPT, and also provide some structure of code based on documentation (as an outline, or first cut).
However, this is the state of the art today. In the future, the training set will be based on the prompt-result output and refinement process, leading me to believe that next generation tools will be much better at prompting the user to provide the details. I've already seen this enhancement in gpt4 recently, I think this is a common and interesting use case.
Overall, these tools will become more and more advanced and useful for developers. Now is a great time to become proficient and start learning how the future will require you to adapt your workflow in order to best leverage chatGPT for development.
You just gave me PTSD; a coworker (another principal architect), who felt that my strategy was flawed, simply gave as his counter-point "I've been doing this since the early 90's, and I've failed with that strategy over and over in the past" instead of providing any answer to my 2 dozen points in support of my decision.
I think mastodon sucks. I think most people think it sucks, compared to twitter- which they likely already use. Is the friction of having a worse user experience worth moving from twitter, just because Elon is being a twit? I don't think most people care because- what is the value of twitter anyway? Most social media is- you get to hear what your friends think, and respond to them. With twitter it seems to democratize access to influencers. Would you switch to Mastodon if- none of the people you care about are there? I don't think so. And if most of those influencers don't move to other platforms, will those other platforms be covered by tech journalists? No.
So if I am reading this correctly, a majority of votes (unanimous) were cast to pass the bill, but this was held in some subcommittee instead of moving to senate floor? Who is this subcommittee, and why do they have more power than the people, plus the senators who voted unanimously?
IF you are stuck with "what" to program, in the mean-time before you figure out what project you would like to start or participate, go to one of the code ranking sites (leetcode, hackerrank) and get good.
Ultimately, this is all you really need to get a job- get good at these problems. Being able to solve them and explain them to an interviewer. Even if you never plan to get a job, it will force you to learn all of the basics that you should at least know about if you plan a career in software development.
As examples, here are some notes I received recently from Amazon and Meta that they send after your initial phone screen with a recruiter:
Amazon tech screen:
------
Technical Prep:
Our technical questions will test your ability to solve a technical problem. If you are rusty, you should study up on:
Trees (binary/red black trees/N-ary trees, tree symetric (inverse image), tree traversal, sorting trees, prefix tree, radix tree)
hash maps, stacks/queues/heap/priority que
link lists/reverse link lists (space vs time)
recursion/recursive strings
binary search
Arrays - 2d/3d
graphs/graph traversal
Big O notation
Meta tech screen:
-----------------
Tips/Things to Know:
Your initial interview will last approximately 45 minutes.
Most people study 1-2 weeks and practice on a coding competition website beforehand (Ex. Medium difficulty problems on a site like Leetcode or HackerRank).
Discuss initial ideas and solutions with your interviewer, which will help you to clarify any ambiguity in the problems.
Take hints from your interviewer to showcase your thought process and problem-solving ability.
Generally, avoid solutions with lots of edge cases or huge if/else if/else blocks. Deciding between iteration and recursion is always an important step.
Talk about different algorithms and algorithmic techniques (sorting, divide-and-conquer, dynamic programming/memorization, recursion). Your interviewer may hint that you’re heading in the wrong direction if you move towards one that’s not optimal.
Think about data structures, particularly the ones used most often (Array, Stack/Queue, Hashset/Hashmap/Hashtable/Dictionary, Tree/Binary Tree, Heap, Graph, Bloom Filter, etc.)
Don’t worry about rote memorization such as runtimes or API/native calls. It's good to know how to figure out approximate runtimes on the fly but the code you write is more important (call out optimizations at the end).
You will be asked about o Memory constraints on the complexity of the algorithm you are writing (and its running time - O(N^2) to O(N) etc.
Please prepare any questions you have before the interview and also be prepared to answer why you are interested in Facebook.
This was part of testing out how well a tool of mine worked (github.com/jsuppe/loom), which aims to be used to extracts requirements, specs, creates tests. At first I had no intention of using it for code generation but then tried it out with some early success. I tried splitting the work by using the tool with different frontier models, and then providing work to a local ollama instance running one of several models. Not all local models had the same outcome, not all coding languages had the same outcome. I also found in this experiment, when nailing down the coding tasks I wanted to set up positive and negative scenarios- which is where I found setting guardrails can sometimes backfire with inversion- this essentially elaborates on previous work by Khan 2025 (https://arxiv.org/abs/2510.22251); the most interesting finding to me was that if you give guardrails with a rationale, it reduces compliance and may cause the inversion
For coding tasks I found that the improvement was not only ability to use a lower cost model for these broken down tasks, but wall clock time was improved over using frontier model alone, with equivalent outcomes.