I don't understand the use of "I'll bite" when the message you're answering to is obviously not... bait. Are we now saying "I'll bite" before every question we ask?
Which model did you get, and how much did it end up costing per square foot (if you don't mind me asking)? Just curious how much the real costs end up comparing with the sticker pricess on their website.
We went with the HO3 (2b/2b 960 SQFT) due to the site. Cost per SQFT is tricky as it depends on what you include in the calculation. Overall less than a stick build.
Overall the price you see on the website is the price for the unit. You need to factor in delivery, upgrades, installation and site design).
As mentioned, it wasn't a cheaper option, but rather a better investment with the quick build and quality control. Our total for the build (with land) was still a savings compare to what is available in our local market.
Back when I was handling it, we were still using Flash for most of the interactive tests, because that was how you had to do it when it was first built circa 2007. Obviously those would have had to be redone in HTML5 since then to keep it working on modern browsers.
I simply don’t agree with the conclusion though I appreciate the approach to thinking about products.
I recently chose to take the train vs driving and the factors behind that decision were:
* Time, yes. Train was approximately the same but an actually a bit slower.
* Cost. Train was slightly cheaper when looking at the true cost of driving. Also significantly cheaper than flying.
* Experience. This is entirely overlooked in the timetable centric approach. Train is simply the most pleasant way to travel long distances (maybe ferry is competitive there). I was able to move around and get work done and enjoy the view. If the train company had swapped my train for a bus I would NOT have been a satisfied customer.
* City center to city center (vs airport to airport). Had the train company said “we swapped the arrival location to the airport but technically we still got you to the city” I would NOT have been a happy customer.
The “trains as timetables” hypothesis would imply that the train could meet my needs via something other than rail travel and would definitely lose me as a customer.
On the other hand, improvements such as better wifi service (it was terrible and not sure why cell service is also poor on a train) or a route that was more scenic but did not impact my arrival time significantly would positively affect my likelihood of choosing train.
So the better lesson is know your customer needs and know their specific jobs to be done and center your hypothesis around this.
I think a lot of that is colored by the fact that you were doing a long-distance trip. I would completely agree with your points if I were, say, living in Frankfurt and planning a holiday in Paris.
But the math is a lot different for regular day-to-day trips, and for that I do think the timetable is the primary product. My goal is to get from A to B, and do so 1) reliably, 2) quickly, and 3) affordably. I don't really care if this means taking the car, the bus, the underground, the train, my bicycle, or a ferry - I'll use whatever option is most convenient.
If I'm only in/on there for 30 minutes, I could not care less for a scenic view. It matters far more whether there is a frequent service I can rely on, which doesn't involve half a dozen needless busy-work with transfers and endless waiting and anxiety for each connecting service. The more it acts like a taxi, the happier I am.
I’ve often thought this would be useful for version control and change review, since it allows diffs to be a lot less noisy. I’m imagining how much easier it would be to review a PR with significant README edits if the file was already structured with semantic line breaks.
I’ve previously had the above thought and applied it to the end of sentences, but the idea of introducing them at the level of semantic thought had not occurred to me. But if this is where we’re going I’d start to wish for indentation possibilities. I’ve do this frequently with SQL statements, introducing both line breaks and indentations to provide a visual structure that mimics the semantic structure of clauses and the details they contain.
Indeed. Edits show up as a -/+ on just the sentence or clause that has changed. Contrast with hard-wrapped text, where a single word change towards the beginning of a paragraph can cause the entire paragraph to be replaced in the diff view, as things reflow.
My father had his eyes fixed like this about a decade ago and purports to be happy with it.
IIRC they did actually require that he wear contact lenses that replicated the effect for some amount of time (a month or so I believe) because there are people who are not happy with the arrangement. So they sort of force you to try before you buy.
Agreed. Many animals without language show evidence of thinking (e.g. complex problem solving skills and tool use). Language is clearly an enabler of complex thought in humans but not the entire basis of our intelligence, as it is with LLMs.
But having language as the basis doesn't mean it isn't intelligence, right? At least I see no argument for that in what's being said. Stability can come from a basis of steel but it can also have a basis of wood.
LLMs have no intelligence or problem solving skills and don't use tools. What they do is statistically pattern match a prompt against a vast set of tokenized utterances by humans, who do have intelligence and complex problem solving skills. If the LLM's training data were the writings of a billion monkeys banging on typewriters, any appearance of intelligence and problem solving skills would disappear.
Much of this post was spot on — but the blind spots are highly problematic.
In this agentic AI utopia of six months from now:
* Why would developers — especially junior developers — be assigned oversight of the AI clusters? This sounds more like an engineering management role that’s very hands on. This makes sense because the skill set required for the desired outcomes is no longer “how do I write code that makes these computers work correcty” and rather “what’s the best solution for our customers and/or business in this problem space.” Higher order thinking, expertise in the domain, and dare I say wisdom are more valuable than knowing the intricacies of React hooks.
* Economically speaking what are all these companies doing with all this code? Code is still a liability, not an asset. Mere humans writing code faster than they comprehend the problem space is already a problem and the brave new world described here makes this problem worse not better. In particular here, there’s no longer an economic “moat” to build a business off of if everything can be “solved” in a day with a swarm of AI agents.
* I wonder about the ongoing term scaling of these approaches. The trade off seems to be extremely fast productivity at the start which falls off a cliff as the product matures and grows. It’s like a building that can be constructed in a day up to a few floors but quickly hits an upper limit as your ability to build _on top of_ the foundational layer of poorly understood garbage.
* Heaven help the ops / infrastructure folks who have to run this garbage and deal with issues at scale.
Btw I don’t reject everything in this post — these tools are indeed powerful and compelling and the trendlines are undeniable.
Does it operate by translating your higher level AI methods into lower level Playwright methods, and if so is it possible to debug the actual methods those methods were translated to?
Also is there some level of deterministic behavior here or might every test run result in a different underlying command if your wording isn’t precise enough?
It's a little hacky, but we have a method in the act() handler called performPlaywrightMethod that takes in a playwright method + xpath and executes the playwright method on the xpath. There's definitely a lot of room for improvement here, and we're working on making observe() fill those gaps. I think observe() aims to be like GitHub Copilot's gray suggested text that you can then confirm in a secondary step; whereas act() takes on a more agentic workflow that you let the underlying agent loop make decisions on your behalf
reply