My team doing front end dev extracted a lot of value from figma mcp. Things that would have taken 3 weeks were done in one afternoon.

Please share an example of what would have taken you 3 weeks and with Figma's MCP in an afternoon.

Do you mean three weeks of manual work (no LLM) vs MCP? Or MCP vs LLM tool use? Because that's a huge difference.

sorry, I was talking about no LLM vs MCP, but in the scenario of LLM vs MCP I think at least 1 week with MCP vs LLM. It's a bit hard to estimae because every project is different, but when feeding our own instructions to the LLM it would still take a long time to UI to look exactly like figma. It could get close enough, but we still needed a lot of iterations.

I'd hazard a guess the former.

The former is a step function change. The latter is just a small improvement.

This is very common and not just during hiring interviews, but also when doing business with other companies across the world. Also, this sort of attack happened before blockchain was big.

I heard about that a few times already, but I never reached a point where my ecs setup combined with other aws services was not enough. If you had everything with just stuff in kubernetes wouldn’t it still be a pretty big deal to migrate?

As a deployment model I bet ECS, fargate and lambda are great. But at the scale of my projects (small) I like being able to run a copy of the full infrastructure (or as much as possible) locally and reuse as much as possible from "prod".

And regarding Kubernetes migrations, once you've made sure you have network and DNS connectivity cross cluster it's essentially just replacing the CSI and LoadBalancer controller. Then the actual data migration there's no magic bullet, depends on what you run.

The USP for Kubernetes is that it's essentially the same no matter where you run it since everything conforms to the Kubernetes API spec.

If you don't want or need local development LARPing prod then anything goes.

So for stuff like secrets management, buckets, api gateways and such, you deploy those services to k8s? And if you don’t mind, is maintaining those services cost effective? I’m asking because I’m always looking to do the trade off of money per time

Kubernetes already has simple secrets, good enough for me.

I would provision buckets with Terraform/tofu, we just use ingress so idk about API gateways.

The eye opener for me was "I can just do this in Kubernetes", which is pretty much always true (though not always right).

Kubernetes + Prometheus + Grafana (with friends), cert-manager, CSI, LB and some CNI you have something resembling what I'd use from $cloud provider.

Deploying K3s is really easy, it can definitely be a time-sink when you're learning but the knowledge transfers really well.

You also don't really need all Kubernetes features to use it, you can deploy K3s on a single VM and run your pods with hostnetworking and local path mounts, essentially turning it into a fancy docker-compose which you can grow with instead of throw out.

I value FOSS and being able to run "anywhere" with the same tools. K8s and Postgres gets me there, I haven't worked on any "web scale" projects though but I know both can scale pretty high.

I personally reached the multi-cloud situation a handful of times - it's particularly common if you're doing anything on-prem, or with customers on certain regions (eg China). If you're truly married to AWS/GCP/whatever stack (fargate, lambda, etc), it's literally impossible to migrate. The successful migrations / multi-cloud setups I've seen all used the cloud provider's specific features sparingly (eg S3 encapsulated on a single library, so migrating is simple), etc

But I agree if you're doing something simpler, sticking to a single provider is fine

But what about other engineering fields? From what I understand, if you compare it to chemical engineering, you have many more similarities, because you’re doing Hypothesis -> Experiment -> Analyze -> Refine -> Repeat, which seems very similar to what we do in software

Mechanical engineering also uses prototypes, iteration, lab testing etc. Building architects build multiple models before the first shovel is put into the ground.

Software is clearly different than "hardware", but it doesn't mean that other industries do not use experiment and iteration.

ok you lost me then xD I was trying to understand what you meant by it not being engineering most of the time.

I will add this link once more.

This is the talk on real software engineering: https://www.youtube.com/watch?v=RhdlBHHimeM

I don’t write any structured specs and I still get a lot of value out of it. I basically use it in incremental steps where I’m telling it what I want at a much lower level. Am always watching what it is doing and stopping it to correct the action. At least for me this approach has worked much better than asking it for bigger things.

Fully agree. Small pieces one step at a time. If you ask it to do something big be prepared for disappointment.

Don’t forget the native typescript transpiler which reduces the complexity a lot for those using TS

It strips TS, it does not transpile.

Things like TS enums will not work.

In Node 22.7 and above you can enable features like enums and parameter properties with the --experimental-transform-types CLI option (not to be confused with the old --experimental-strip-types option).

Excellent update! Thanks!

Don’t use enums. They are problematic for a few reasons, but the ability to run TS code without enums without a build step should be more than enough of a reason to just use a const object instead.

Oh, I agree.

It's still not ready for use. I don't care Enum. But you can not import local files without extensions. You can not define class properties in constructor.

Enums and parameter properties can be enabled with the --experimental-transform-types CLI option.

Not being able to import TypeScript files without including the ts extension is definitely annoying. The rewriteRelativeImportExtensions tsconfig option added in TS 5.7 made it much more bearable though. When you enable that option not only does the TS compiler stop complaining when you specify the '.ts' extension in import statements (just like the allowImportingTsExtensions option has always allowed), but it also rewrites the paths if you compile the files, so that the build artifacts have the correct js extension: https://www.typescriptlang.org/docs/handbook/release-notes/t...

Why not import files with extensions? That's the way JS (and TS) import is actually supposed to work.

I have to admit I was a bit surprised when I was suddenly expected to get rid of all extensions in import. Sure, looks clean, but is it right?

Why would you want to do either of those?

Both are very common Typescript patterns.

Importing without extensions is not a TypeScript thing at all. Node introduced it at the beginning and then stopped when implementing ESM. Being strict is a feature.

What's true is that they "support TS" but require .ts extensions, which was never even allowed until Node added "TS support". That part is insane.

TS only ever accepted .js and officially rejected support for .ts appearing in imports. Then came Node and strong-armed them into it.

Maybe common in some legacy code bases. I recommend running with `erasableSyntaxOnly` for new code bases.

Exactly. You don't even need --experimental-strip-types anymore.

I’ve been working with Elixir professionally for the past 7 or 8 years, and I have to say, phoenix and are great, but it’s the repl I miss the most when I’m building in other languages. The ability to interact with a system, ask questions, try code, is crucial when I’m debugging