I certainly wouldn't try to do the refactoring and optimizing (actually, this is more like a complete new feature) at the same time.

First, make it work, even if it will make the code look ugly. You're not going to save any time by doing both things at the same time. Refactoring something that works is a question of 10 minutes in Visual Studio.

Trying to figure out whether it's the refactor or something else that broke the rendering (if you try to do both things at the same time), takes way more time than those 10 minutes...

I think I need to make an indices buffer, but I have no clue how to pass my vertex buffer to it. When I'm drawing the cubes, I'll be drawing from the indices list so hopefully it'll make the fps jump

I changed the class to this so the vb is only being called once but nothing changed

    public void setVB()
    {
        device.SetVertexBuffer(cubeVertexBuffer);
    }

    public void Draw(BasicEffect effect)
    {
        setVB();

        foreach (EffectPass pass in effect.CurrentTechnique.Passes)
        {
            pass.Apply();
            device.DrawPrimitives(PrimitiveType.TriangleList, 0, cubeVertexBuffer.VertexCount / 3);
        }
    }

How much difference is there in the shader setup for each cube? As it is the shader setup that is most likely causing the slow down in your application, especially if the draw call is small.

Also start using a Version Control System so that you can easily switch back or diff to a working state, I have my own perforce server at home on the same box as I develop on. Which allows me to revert back to a working state if I manage to mess up my code to badly.

It wouldn't be but it would be easier for an artist to work in blender/3ds/maya/or other 3D package. Editing the world position of that cube shouldn't be hard in the engine however but modifying specific verts might be. As there might be more polies in that cube then you expect.

If your cubes verts are already transformed, you could do the shader setup only once and then just call draw on all of the cubes, this probably will not give you all of the performance back but you might get some.

I never even thought about that. My laptop is 3 years old and cant even run diablo 3

I never even thought about that. My laptop is 3 years old and cant even run diablo 3

Having a slow dev machine is actually a very good thing. It forces you to prioritize the optimization efforts sooner rather than later. Which is the best way to get a deeper understanding of the API, gfx concepts and techniques (at the cost of less features, since your free time is pretty limited).